JPEG XL

Dzgas, it's not ideal to benchmark a codec using just one image that is literally just pure noise. Test other images please, like ones from a camera maybe?

I just proved that's not the case, it's an issue with XYB

Well, I can send you an image of the (this) rendered full of the sound wave, which I made with a self-written code for myself alone, in the original 1 wave sample per pixel with a wave phase to imitate 3D. Unfortunately, the "technological canon" is that an image larger than 16k x 16k is blocked anywhere like a Bomb. Therefore, I use a reduced resolution by 2 times. I can send you the original image, for example via Google Drive, is that okay?

Sure send it my way <:Yes:1368822664382119966>

https://drive.google.com/file/d/1qdMpZrij0YTD-2zuEbniTmt9cAdETGz3/view?usp=sharing

Cool, looks like the spectrogram graphs you can generate with sox

I bet jxl would hate those

JXL really does suffer compressing artificial images like these, which make them excellent for seeing the yellow be destroyed, which can help us diagnose what's causing it.

Well, I was wondering what formulas and algorithms exist that can draw a pixel-by-pixel image of a sound wave. And why no one uses the phase of the wave to create a three-dimensional effect... which is what I did. And you can see other works here https://discord.com/channels/794206087879852103/806898911091753051/1378846989000900733

and it already happened that my image contains all the colors where Jpeg XL has a problem -- yellow, blue, red

Good

I'm a little surprised that Jyrki didn't notice the desaturation first. It could be a combination of many different factors.

no... that's the thing, I've been writing about it for as long as I've been sitting on this server, and HE personally has already worked on it a lot, it's just that the results are extremely local, not global

https://discord.com/channels/794206087879852103/794206170445119489/1209542475258269766 year ago https://discord.com/channels/794206087879852103/794206170445119489/1107310666597007451 2 years https://discord.com/channels/794206087879852103/794206087879852106/1040982426102538391 3 years ago

it's just that the problems used to be so outrageous that it was impossible to look at it without crying... although, looking at my image, it's also hard not to cry. In general, I see that the work is going on, but I really have the feeling that there are 2 people working on jpeg xl

That's why Jonnyawesom3 and I are going to talk to him directly in VC one of these days. Maybe Jyrki is not "trained" to see this kind of compression. Or maybe his eyes are just not sensitive to yellow. ~~Or maybe he is secretly colorblind!~~ jk 😂

https://cdn.discordapp.com/attachments/794206170445119489/1107290961375154247/well_well_well.png?ex=683da011&is=683c4e91&hm=8b62b3f1e375e3e1f5d2e7a0264756bb0f897dd8af33ec9c836343c740ea3d0d& you can take my test image collection right now that i used a few years ago and see how bad jpeg xl still is

full set here https://cdn.discordapp.com/attachments/794206170445119489/1209510866115100722/merged_image_color_sort.png?ex=683db8c6&is=683c6746&hm=5e185289645c6d63c1e23dfdeff470cbae894babb99b157724fd4f2af7c060a4& but, as practice shows, most of its finally look normal, without the problems that were there before

it would be funny

I first noticed it when I saw the flowers in "detroit abandoned factory" image get dulled.

But then I saw that almost every color image has the issue to some extent

Jyrki’s brain uses a weird transfer function maybe

It could be an unfortunate combination of the primary colors in his screen and the spectral response of the cone cells in his eyes maybe? Too many possible variables to say

I have a hard time noticing the desaturation too. If I know where to look and I zoom in enough, I can see it, but it's not something that jumps at me like it does jump at some people here.

It's good to have eagle eye people with different sensitivities so we can find these issues.

I am not worried about the jxl bitstream expressivity to be able to overcome the issues. The XYB transform is actually parameterized (we just use default parameters all the time) so if needed it can be adjusted. The shape of the quantization tables can also be adjusted (we currently only use default tables all the time). We could use different gaborish kernels or make them depend on the component (we currently only use the default and it's the same for X,Y, and B). And of course the heuristics for selecting block types and adaptive quantization weights etc can also be tweaked. There are many degrees of freedom that are not used.

so the JPEG XL bitstream lets you change literally everything?

anything that has weights that can be changed without affecting decode speed has default weights which seemed to work well and also a way to signal other weights

can I make XYB act like a different colour space

these parameters can be adjusted

the only thing that is fixed is that it's a biased cubic transfer function

(allowing arbitrary exponents would have impact on decode speed; computing a cube is way cheaper than an arbitrary pow)

How are the floats given with that much precision? Is it assuming 64bit? It says f16 though..?

not sure if the defaults correspond to exact f16 values or to f32 values. If they're signaled explicitly the precision is limited to f16, but those can still have a long decimal expansion

They look almost f64

15-18 decimal digits = around 50-60 bits = matches 53 bit mantissa

I just wrote as many decimal digits as we had in the source code there 😛

hehe

in the new rust codebase, we have a bunch of `#[allow(clippy::excessive_precision)]`

I knew of the custom quant tables but custom transform is new to me. That could make it significantly easier to solve the desaturation, as it's due to the extremely narrow range of B where yellow is fully saturated.

https://discord.com/channels/794206087879852103/794206170445119489/1376777713184145408

Looking at my examples on my phone, I don't see anything. On my desktop, it's obvious

https://www.reddit.com/r/AV1/comments/1l2hd3w/youtube_employee_confirms_that_the_poor_av1/ so apparently there was an actual issue that made yt encodes noticeable worse, while it's nice that that is fixed, yt's av1 will still remain within margin of it's vp9 encodes

Thank God it's going to be fixed

YouTube still haven't terminated my shadow ban for over a year

the best quality is not reencoding uploads at all

or let local uploaders and applications preprocess all that locally until the file matches youtube's supported formats

content creators use video suites like vegas and resolve on powerful machines that can encode 2k-resolution faster than realtime

not re-encoding has it's own set of issues, for instance when I dump 20mbps video at yt [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&name=av1_dogelol)

but it's also fairly important for security and what not

yeah, they probably want the right pixel format, the right frequency of intra frames, a specific maximum short-term bitrate (not just overall average), etc.

and multiple qualities anyway

imagine if someone uploads a lossless video on yt

also you dont want videos that spike bitrate really high

only one specific format/quality combination could be the original uploaded by the user (assuming the user can only upload one file with one stream)

I know lots of people who upload prores 444hqx or whatever its called. which is way higher bitrate then a lossless x264 or probably even ffv1

so it might as well be the highest quality possible, which then benefits all of YouTube's encodes

I upload mine in DNxHR+FLAC if I export them from DaVinci Resolve

dnxhr is nice, I wish it wasnt so picky when exporting via ffmpeg. that took me way too long to add to olive

is DNxHR the non-apple ProRes?

yes

TIL 4:4:4:4 (it’s 4:4:4 + alpha)

Also a texture format.

I wanted to make a small yuv420 comparison webp jpegli mozjpeg but already on the first picture it is absolutely obvious that all these tests do not make sense, webp is completely better than jpeg in any implementation. With identical file size ``` webp -q 58 -m 6 -af -sharp_yuv mozjpeg -baseline -notrellis -sample 2x2 -quality 33 -tune-psnr -quant-table 1 cjpegli --noadaptive_quantization --chroma_subsampling=420 -p 0 -d 3 ``` all files out 28 KB Original | jpegli | mozjpeg | webp

It's even painfully amazing that the webp 420 looks even better than the guetzli 444, in my opinion ```guetzli --quality 82 webp -q 58 -m 6 -af -sharp_yuv ``` Original | webp | guetzli

(I think it's not worth mentioning that JPEG XL can't encode normally this image at all, and may even look worse than jpeg due to color discoloration due to XYB)

I feel like I just said this, but it's not ideal to determine a codec's worth using just one image, especially one that is literally just pure noise. Test other images please, like ones from a camera maybe? Perhaps even some memes from social media? Ya know, regular and common images shared on the web? When we say jpegli is better than WebP, that's what we are talking about. At best this test just shows how necessary sharp yuv is for color retention when you lack the ability to use 444. Speaking of which, <@703028154431832094> here is a visual example clearly showing how super thin colored lines are preserved with sharp yuv. It boosts metrics and psychovisual quality when compared to regular 420, I'm assuming 444 would still be better at reasonable quality ranges though.

Also, why did you disable AQ and progressive?

AQ is blur shit disable progressive just a habit, I have a thought in my head that the division of data into different segments should be wrapped or marked with some minimal service data

I don't see any reason to do as you say. In that case it won't be a universal codec, but a codec only for photos and memes

or Jpeg XL is no longer a codec for Art? because AVIF compresses Art better?

JPEG is bad for artificial images, JPEG XL can use modular mode

this is slightly lie or rather an inconvenient truth, because libjxl itself does not choose which algorithm will be used for lossy encoding, modular or vardct, depending on what image is at the input

the fact that lossy modular exists is great knowledge, because it is not typical for a format to actually have 2 different codecs for lossy. webp has 2 completely different codecs. avif has only 1 codec. but jpeg xl is a unique thing in this regard, but **no one** demonstrates the the advantages of lossy modular anywhere at all, because the algorithm itself is very raw, as far as I know, it is just bad. although in theory it could solve the problem of ART-image compression. But as I understand it, this is not a priority

The possibility is there https://discord.com/channels/794206087879852103/794206087879852106/1368950237082816563

Oh nice, that’s cool; it’s definitely obvious here

I'm not talking about JXL here, you're missing the point. I was talking about the strengths and weaknesses of both WebP and Jpeg. You bring up "universal codec" as if Jpeg and WebP are universal codecs??? They are clearly not, both of them have very clear limitations in compression, resolution, features, etc. Even if WebP beats Jpeg with all images in terms of compression, there are other features Jpeg has that would make it worth using over WebP depending on the situation (progressive!). Compression is valuable, but not the only factor (an example would be jpeg 2000). Also, in these tests which clearly favor WebP, it's kind of embarrassing how close Jpeg is considering WebP was created in 2010 compared to Jpeg's old 1992 tech.

The bottom line is, the desaturation problem is severe and noticeable even from a distance.

I can understand that it's subtle enough that it still might depend on the viewing environment and cone cell reaponse but it's obvious to me even in multiple viewing environments.

And I'm not the only one

Once this issue is fixed, then that's the biggest issue gone.

The chroma ringing problem looks fixed to me, I think. Thanks to Jyrki's latest tweaks. Thanks Jyrki!

So that's 1/3 major issues already seemingly fixed. Good progress.

There are lots of issues that are not related to quality, as well

It doesn't make sense to test encoders sub-optimally. `cjpegli` stands out with 444, XYB and AQ and over 70 quality `avif` stands out with 10bit, 444, tune=iq `webp` is hard limited to 8bit, 420 and std gamut which makes it practically useless in 2025. That being subjectively better on a single image (an obfuscated one), and a single quality level (very low) doesn't mean anything in my opinion.

your message is not helpful

speaking about jpeg 1992 probably in tests it is necessary to use the encoder of 1992. isn't it? jpeg has advantages, for example when compressing q98 444 there is almost no real difference in quality with the original. but as practice shows this is a meaningless superiority, still no one really uses it for its intended purpose because why???? if you want quality take png. and webp ideally demonstrates this with the complete absence of 444. because this is a precise clear technical feature. and those who made the codec knew exactly what they were doing just like the browser is forbidden to display any image larger than 16384, webp has no need to be technically larger. everyone talks about the advantage of yuv444 but are you really using it??? if you want to keep the original, better to use loseless. these codecs are universal, no need to argue with that. just like google maps are hundreds of thousands of block images, no one is crying about making a codec to store the entire google map in one image, to decode it block by block by 256 pixels with progressive decoding. yes jpeg xl?

oh you made a new cool jpeg encoder wow cool..... by the way why does your site still use a codec that is 30 years old? <:Thonk:805904896879493180>

There certainly are cases where yuv420 is just not good enough. Any red text or logo will get blurry, for example.

For websites: JPEG = compatibility + true progressive loading AVIF = Best lossy compression (low & medium fidelity) WebP = Okay lossy compression, however its lossless mode is amazing. I guess the question is, why would I use lossy WebP when AVIF exists? Lossy WebP is a strange middle ground where it sometimes compresses better than JPEG and is slightly more compatible than AVIF. So it does neither thing well. If you want lossy? Use AVIF. Want compatibility? Use Jpeg. Want lossless? Now here is where WebP shines best. JXL isn't adopted yet, but if it was then it would fulfill the role of lossless and high quality lossy (along with progressive and compatibility with JPEG)

Also, I think there might be some kind of miscommunication here. When you were using the phrase " universal codec" I thought you meant it could compress all kinds of images "universally". The reason I thought you meant this was that you mentioned codecs "compressing well only for memes and photos" mentioning JXL not being good for art and the like. However, now you're talking about "universally used"? I'm confused.

too vague an argument. if the logo is minimalistic, it's better to compress it losslessly. and if it's highly detailed, will it be noticeable? don't we use yuv420 precisely because our color sensitivity is worse. and webp perfectly solves the problem of color compression with the sharp_yuv parameter, although I still have no idea why it's called that. the setting only increases the quality of the color layer

Also logos would probably be better as SVG

there are few different class of image: photograpic: 420 is fine (on web) non-photographic: probably lossless / WebP near-lossless is better Simple flat colours/diagram/logo: SVG

I should also mention that AVIF can do sharp yuv 420, outclassing WebP entirely

webp is supported in all existing browsers, there is no more compatibility issue. it is just supported everywhere, and yes, on iPhones, and on MacBooks. this issue is closed. avif is a failure, because of the speed of encoding and decoding. this codec turned out to be too powerful, it is not ready to be used. of course it can be used, but still, where is it? I do see sites where it is used, but it is a drop in the ocean. webp is much more appropriate, simpler, more flexible, it just works. it is sad to have avif which is positioned as a codec for low quality compression. to have 10 bit hdr yuv444 lol

https://netflixtechblog.com/avif-for-next-generation-image-coding-b1d75675fe4 is not that crazy a use case where you have images containing a mix of photo and non-photo

sure, ideally you'd use something like PDF where you can combine raster and vector elements and lossy and lossless payloads

Can’t SVG also do the same?

yes

so why would you use PDF on the web

like embedded

I mean, no one will use codecs for their best features. In reality. They won't do it. I can do it, I know all the pros and cons of all codecs. But people will just look: "hmm, this is something new and it says that it's better, I'll use it." Codecs are just universal, and not for pictures or photos or arts separately

in SVG you have to use base64 to embed raster images, so it's not quite ideal

if you serve it with gzip or brotli, most of the overhead of base64 can be compressed away but still

I don't know if it's a language barrier or if the sleep deprivation is getting to my head, I don't understand what you are talking about. I'm going to sleep now

it's good to be netflix

Ok

anyway, it requires a pretty careful workflow to get mixed image content like those movie posters (or all kinds of marketing material, infographics, etc) from authoring to end-user delivery while keeping everything in the right formats (vector, lossless raster, lossy raster)

also there might be reasons to not expose the layers (which makes it easy to e.g. edit the text) but have a flattened single raster image instead

anyway, point is: you can't just say "better not to use lossy for logos or text"

FWIW, caniuse says that 93.57% of browsers support AVIF while 95.62% support WebP

I can't sleep thinking about this: Yandex images have completely switched to webp. 100% But Google images haven't. Although Google created webp 15 years ago. I can't sleep without thinking about whether they are really use jpeg because the site loads faster, because jpeg decoding is 3 times faster than webp. Is that really true... Because avif was on YouTube, and then it completely disappeared, only jpeg and webp remained. <:PepeGlasses:878298516965982308>

this has a direct connection — why google has been explores studies research jpeg so much. cancelled the webp2 project. butteraugli is also a google project. in 2017 releasing guetzli as a result of the jpeg study. then with the jpeg xl project releasing jpegli. as if jpeg xl is just an excuse to make people come up with technologies that they will then apply to jpeg

<:monkaMega:809252622900789269>

this also has a direct connection to why google cancelled jpeg xl support

that means nothing, as the content might not even be shipped by any website. webp and avif are in the bad spot of being final delivery only formats that are used principally by cdns (converting + recompressing what are original jpegs and pngs)

on support %. for *mobile*, jxl has as high as 44% support in US, canada, UK, japan

on the macos+ios ecosystem, its now apparently as high as 85-90% of all apple machines that have succesfully connected to an apple website *at least once* in the last year

jxl's woe with delivery is that even when its available, other formats are given higher priority and almost exclusively displayed instead. filesizes are often given as excuses but a 100 kilobyte image consumes the same storage and bandwidth regardless of the format its in. providers like cloudinary shouldve made extra certain that jxl is always at least the same size as web/avif and never bigger

True Techno psyop: Why Google stubbornly bans jpeg xl in chrome. And why they refused to use AVIF, which they work themselves in 2018. Why Google, instead of supporting the new one, is already releasing second jpeg encoder

I checked YouTube, and I'm definitely being served avif images (at least for the thumbnails)

is that even an actual ban? i recall the decision being more practical and being open to re-evaluation. we called the blatant BS but some necessary procedures werent followed to ensure smooth adoption. "origin trials" for chrome and its firefox equivalent are mandatory for such high impact changes but now cant be done for chrome cuz the integration code no longer in place. even small websites can get origin trials approved (which basically force-activates a specific browser flag for just that website, wich couldve been jxl decode for a cdn or social network, handy for testing impact and server load - 'no interest' may have meant no website had shown intention to actually participate in origin trials and support remained textual). upcoming integration of jxl-rs in firefox will still require this before it can enabled by default anywhere

jpg avif <:Poggers:805392625934663710>

aomanalyzer confirms it's an avif

yeah, I don't know why they went that route 🤦‍♂️

an interesting observation. Maybe that's when I saw it, because in recent years I've downloaded about 200,000 YouTube previews, and there hasn't been any avif

There's clearly something wrong here.

so

this is really something that I would not have been able to notice through the API Google will replace the link if it is obtained with a special key. As I understand it, when the page is loaded, a certain script is executed that generates a key, and only with this key is the cover available in AVIF. Otherwise, Jpg or webp is returned

I wonder why...

could be to gimp unofficial/old clients like smarttvs still using html5 wrapper apps

if you follow my psyop theory, could it be that google is benchmarking the system in real time to decide if the device is powerful enough to decode AVIF. Because if it was just a matter of support, they would have done the same as with WEBP, simply outputting another link if there is webp support

<:FeelsReadingMan:808827102278451241>

yt and dirty tricks, name a more iconic duo

and yet, it all sounds somehow unclear, there were no sites, well, is that a problem? well... so my theory, although it seems like nonsense, sounds technically correct

100% preview on google images is jpeg. Not even a single png

i think this happened after the recent changes when thumbnails became very large maybe this is still an experiment with conversion from the highest resolution jpeg also, i haven't noticed using avif in firefox, but in сhromium-based browsers they are quite common

By the way, I'm a bit trapped here, because now I don't know if they removed AVIF at all, but I definitely remember that half a year ago, when I looked at the same thing, there were only WEBPs. Maybe they cancelled AVIF 4 years ago, and now they're experimenting with bringing it back. And indeed, because of the experiments with changing the preview size, AVIF has become more profitable than WEBP...

I think you're right -- YT is either still rolling out avif support, or their detection mechanism is faulty somehow

yeah, a lot has happened to libaom during those 4 years

btw, the main reason for making WebP is YouTube, not just some internet images, not photo sites, but exactly YouTube, because in a certain period of time, images and previews from YouTube consumed more traffic than any other site with images or photos, and Google wanted to reduce it somehow without YouTube, WebP would most likely not exist as far as I remember, this is almost a direct quote from one of Pascal Massimino's speeches and now avif is also used to further reduce traffic

"btw"

as if it were obvious, bought a video compression company just for that, vp8 vp9 just for that. webm just for that, and webp of course

when you get a .jpg that is actually another format like webp or avif, it's because the cdn is using a proxy. Basically you ask the cdn to give you file.jpg the cdn looks at your headers (or the url option thingy) and sees you support avif, and serves you an avif instead

we just live in a time when vp9 720p video looks better than av1 720p video with the same file size. It's just unthinkable. this is YouTube moment 🥴

this is standard afair for how CDNs work.

oh, I'm aware of the CDN auto-select mechanism

the issue is that when you try to download the image, it's still being downloaded as a ".jpg"

so you'll need to manually change the extension to ".avif" for it to get recognized appropriately

oh that's because browsers are dumb

iirc there are extensions to change that

is there any user-installable extension that can always load jxl images at the highest priority when multiple formats are available? i thought the selection logic was imposed by servers and you could only pretend webp/avif arent supported but even then the fallback is usually jpg/png

no.

you would need per CDN awareness

you can set jxl has the first in accept order , but that's kind of an unofficial thing

I do have a redirector script for some of the CDNs I personally know of, but its on my desktop and its way too hot rn for me to go there lol

yeah, but google also had other services, like google play, photos, ads, news, maps, picasa, and others, where images and photos seem to be more needed and used and youtube is just for videos, as many people think, but it was youtube that pushed for a new **image **format

not all videos and not every acene, there was a bug that caused videos to look even worse

any video with nature and grass is blur-block shit

back in 2020 i thought it was temporary, maybe it will get better soon, but no, in 2025 it still isn't

but since youtube allows you to turn off AV1 directly in the youtube account settings, it's obvious that everyone knows everything

my reference is this https://cdn.discordapp.com/attachments/1163724584311345154/1380096276925906945/image.png?ex=6843f3d1&is=6842a251&hm=49a1d2a194d81d2019db64ba5b4a3d4630174cb846b8095c5d5d63bfa415f8e3&

it's a rate control bug on youtube encoders/encoding ladder, the same thing sometimes happens with vp9, where some frames are very low quality and it turns into a blocky mess, especially if it's key frames

A lot has happened in 2024 alone

Huh, the yellow lines dissappear when I tap on it

like, when you zoom *in* do the yellow lines disappear?

Opening in browser is fine, opening in the app the lines are gone regardless of zoom

huh 🤔

did I generate a schroedinger's pic? 😂

it behaves normally on my end though

Same here <:KekDog:884736660376535040>

Is the one on the right vp9?

It's server side but you can try modifying the HTTP Accept header

A lot of broken sites and CDNs expect very specific Accept headers

Like for example a lot of sites break if you don't send them at all

http needs to die

Yes, av1 encodes on YouTube for a long time was a horrible blurry mess compared to vp9. The bug/issue only recently got fixed like last week 😅.

Nowadays AV1 should give similar a quality video to vp9 at a significantly reduced bit rate.

yes

sounds like a lie. It was like this for 4 years and no one saw? yeah right?

<:Thonk:805904896879493180> Isn't it obvious that they lack power, so they presets downgrade and set too fast parameters of AV1 -- av1 look worse than VP9 even at the same bitrate, due to different complexity and architecture of codecs. AV1 is not intended to be encoded on fast presets, it is better to Use VP9 bacause which for the same computing power will make a better picture quality

Nope. People saw and complained. It's Google's fault that it took them this long to fix it.

no, it sounds like there are 2 people working at google, don't write that

??????

there are people who organize super-giant computing complexes the size of stadiums, just to compress in the AV1 codec. And I just don't believe in the way you demonstrate it

can't just "not see it". Your explanation is too contradictory to how the world works

You are acting like Leyley.

since YouTube doesn't encode all videos in vp9 even in 2025. and even more so doesn't encode everything in av1. They definitely have problems with computing power, and they decided to solve this problem by reducing the preset, while the BITRATE parameters are set as LOWER than vp9 in order to fulfill the main goal of AV1 - to reduce traffic. This led to a small collapse. I also noticed that Google removed millions of vp9 encoding options for some old unpopular videos. Because the video that I downloaded 2 years ago in vp9 720p no longer exists on YouTube itself, only AVC remains

true, but your arguments are ridiculous

they don't? I thought they did by now I havent seen an avc only video in a long time

Maybe you don't watch videos that have less than 10.000 views, I guess

every video on youtube has only one format vp9 - it is 360p. The rest is not necessary and depends on the number of views

even then I see lots of videos with sub 1k views that have vp9

I downloaded 108 thousand videos from YouTube as part of one archival project, I am confident in what I say

dunno then, guess its probably just random https://cdn.discordapp.com/emojis/654080960492732435?size=64

and I also indexed 643,490 shorts and 742,231 videos that had gacha life in the title

just

☝️ <:galaxybrain:821831336372338729>

for 1080p resolutions and below, most non-popular videos are not encoded in vp9 for 1440p+, almost 100% are transcoded to vp9, unless it's a bugs or something unexpected

true

This is due to the fact that avc does not support resolution higher than 1080p............ Well technically

level 6 and above are 4 stitched together avc video that are located on one screen, which is slightly not legacy

and this decision is more likely related to their hardware avc encoders which can't do that

so all 1440p videos are necessarily encoded in vp9 regardless of the number of views <:VP9:981490623452430376>

this used to be the case but I still often see 1080p on lesser view videos, perhaps its on a per creator base?

it may be that an unpopular new video in 1440p is just not ready. the author posts it as is, when only Avc 1080 is ready

hmm, maybe its around 500 views?

as far as I know, it depends on the predicted viewership popularity and about not having enough encoding capacity, even av1 streams are currently being transcoded at 100%, as long as some conditions are met, with real-time encoding up to 1440p resolution, even though the av1 live stream announcement said it only works for big streams, with 10k+ viewers

also, av1 transcoding works for 8k resolutions uploads and also with 100% even for private channels with 0 views but, not sure if this still works

8k doesn't exist anymore. It's banned. Only those who managed to send to have it <:Google:806629068803932281>

anyway, the encoding capacity is enormous, and it's not CPU encoding, it's hardware encoding with custom ASICs, so it's pretty limited in terms of presets and speed options maybe there's something like a faster preset for quick initial encodings of popular videos and live streams, and a slower, higher-quality one

or maybe AV1 turned out to be so complex that for fast hardware encoding they implemented less than half of the entire codec While vp9 was originally designed with this in mind, google for themselves, and is used entirely

<:Thonk:805904896879493180> Unfortunately, I don't have personal equipment from Google servers, which they personally design and produce only for themselves, so I can't make a AV1 encoder comparison

vimeo also uses avif for thumbnails <:avif:1280859209751334913>

does anyone have ready-made functioning `jpegli` builds anywhere?

Nightly dev builds of libjxl have jpegli bundled https://artifacts.lucaversari.it/libjxl/libjxl/latest/

theres no **.dlls** anywhere (a jpegli *executable* is inadequate for most uses). imo thats the most crucial missing element of the library that's supposed to be fully swappable with whatever. right now you have to pull jpegli's source into your own code and have no immediately usable dlls you can ship unmodified into your apps

crunchyroll also shows jpgs but avifs

👍 <:AV1:805851461774475316>

I am a very knowledgeable person, but I have no idea why they do this. If AVIF is still stored physically in another file, why make such a complex system of distribution from a jpg link....... <:Thonk:805904896879493180>

I have some suspicions they're using rav1e as their AVIF encoder <:Poggers:805392625934663710>

fixed 16x16 transform partition with segmentation enabled screams of high-speed rav1e

thats extremely specific 👀

exactly

my money is on them using kornel's cavif

<:SadOrange:806131742636507177>

the image was also encoded in 10 bit mode, which is the cavif default afaik

so final answer: cavif

the fastest and safest encoder doesn't need updates <:avif:1280859209751334913>

when I was updating my fork SVT-AV1 -- looking through all the commits for half a year, I realized that nothing ever happens <:SadCheems:890866831047417898> 👨‍🏫

rav1e has stalled completely (lack of funding 😦 )

SVT-AV1 is about to get a significant upgrade actually

https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2443

random access is improving slightly, while low delay and all intra mode are improving tremendously

I watched the latest version about 4 months ago, my conclusion is that the codec is broken, they killed it. It's just unbearable, I created my fork a year ago and the new codec is just worse and worse and worse. I don't even know how to compare them.

in what way is it broken?

instead of preserving details, it does everything in blur, just on 1080p crf 50 it feels like I'm watching 360p. At the same time, the emphasis on what algorithms to use when compressing is some kind of joke. In fact, it would be nice to make new comparisons to show this to everyone, maybe someday. instead of using a more complex algorithm for fixing the division of the block into subblocks, they do nothing, and artifacts of 64x64 sizes appear due to the fact that the giant block is not moved correctly and is not divided into smaller blocks. I can talk about the problems for a long time, that's why I made my fork, so that I could compress for myself without worrying about these problems

I see, it does sound like a comparison would help everyone understand the issue you're describing

my -- "super-placebo" fork "for games and '-1' " on preset 7, which I consider the minimum for this, and I never use it on this, but still. notmy -- last git ffmpeg build SVT-AV1 Encoder Lib v3.0.2-49-g5def505f no preset 5 my2 -- my standard fork no preset 6 everything was coded in same time within the error margin of 10% all parameters svtav1-params are identical crf was selected for the identical final file size

the source https://www.youtube.com/watch?v=49mseQwFeO0

1280x720 encoded bitrate ~300

Have you ever considered it looks like 360p because you're giving it 360 kb/s? :P

if i need higher bitrate i will use hevc lol why do i need av1 with high bitrate, it is completely useless already on crf 30 and gives almost no advantages

<:Thonk:805904896879493180>

I took a quick look at the three videos, and it seems like they trade blows with each other? "notmy" is sometimes sharper, sometimes more blurry than "my" and "my2"

but I'm not sure if we're looking at the same parts of the video

yes, half a year ago i would point a finger at svt's problems. but now i can really say that they are roughly on the same level, but in completely different things

so the "broken" version you mention here was v2.3?

my | notmy | my2 2.8 sec

yes, everything I tested from 2.0.0 to that

I see, now I get it

Here is an excellent shot that shows that the new latest 3.0.0 has problems

SVT-AV1 does tend to progress in a "two steps forward, one step back" way

something like that. but since I monitored all the commits, they change too much and globally, instead of moving a little

but globally nothing happens

it's paradoxical, after version 2.0.0 they completely rewrote the entire rating system. Instead of fixing it little by little, but I didn't even have anything to take from there, because everything is different there, and in general I think they did everything badly. It's like when jpeg xl 0.7.1 loseless shows better compression than the latest version

here is one of the tests that scared me

and svt-av1 is all like that

what's scary about it?

this line shows that changes are being made to the codec that change its structure too much, and I get the feeling that they are doing too little testing to check the quality of the innovations

it just means the encoder tries to adjust internal knobs to counteract the fact that higher CRFs tend to encode faster, given everything is the same

it's normal because there's more or less information, but look, the new version is red.

yes, the MR preset (-1) isn't tied to any expected speed level

in fact, MR will become much slower in v3.1

interesting. because I also made a fork with inflated parameters, in my opinion. Having created the most powerful av1 encoder. A good reason to test it. But only here I have ffmpeg with 3.0.2

the main thing is not to forget to increase the number of commits

Switch from YASM to NASM AVX2 fixes Load optimization for 2-5 cores this is all that I took between 2.0.0 - 2.2.0 from useful, the rest is garbage

Vaguely reminded me of the libjxl v0.9 change. Overall made the image blurrier, but made certain lines and features much sharper

android 16 saves hdr screenshots as pngs with gain maps -- test files if anyone wants (not uploading as images to discord as it seems to strip the gain map)

not sure if anything can show these in hdr besides google photos on android 16 <:KekDog:805390049033191445>

some info on the format https://skia.googlesource.com/skia.git/+show/0d94e966268bbc200ea57e074f33afca6321e483

PNG-ception

and speaking of hdr pngs, they're currently broken in chromium (https://issues.chromium.org/issues/423310049) and in firefox the tonemapping to sdr doesn't really work anymore

that's specifically regular hdr pngs, not using a gain map

e.g. https://discord.com/channels/794206087879852103/824000991891554375/1285152978235559970 used to look fine but kinda washed out in firefox, now it's just really dark

oh I think I know what broke them

and the person that broke them 😛 I can probably help them fix it

I didn't help but the PR should be ready

<@297955493698076672>I was testing vp9/av1 because I was *scared* by the technical loss of av1 on presets 6 and higher, on crf 45+. With identical encoding speed, av1 is only slightly better, very unnoticeable. But this also became a reason to compare 3.0.2 av1 and my fork av1. and what can I say, here's what I was talking about, the sizes are the same, the encoding speed is the same, but the problems are noticeable. av1 3.0.2 | vp9 | my fork

Why does av1 sometimes lose to vp9?

due to the much simpler design of the vp9 codec, which gives an advantage in faster encoding, when AV1 is drowning in technologies that are used halfway, vp9 uses the maximum of what it has. Here is revealed that compromise that few people talk about ... AVC also has this, at resolutions of 540p and below, it can demonstrate quality better than HEVC and VP9 at lower presets. And also the reason why the first Intel ARC video cards issued hardware av1 with WORSE quality than avc

Good answer

EVC (MPEG-5 Part 1) followed the way of vp9. But it's just a laughing-stock

What do you mean? It's simpler but people don't take it seriously because of that?

it is not better, not faster, being in real competition this codec is useless, I tested it, I do not understand why they create it. just like that... practical work for students probably

Now there is a gradation of codecs by need, speed/quality. AVC - HEVC/VP9 - AV1 EVC is nowhere in this gradation better, neither in speed nor in quality

Well of course, if you're comparing an unoptimized experimental codec with a mature and optimized codec that's to be expected that it won't realize any advantages until it matures

I disagree with this argument. If a codec doesn't demonstrate advantages at the time of its release -- under what argument was it initially made?

EVC is a real "yet another codec" just for be. Even VVC doesn't look as funny as it does.

there is a "scientific argument" that during the study and development of some technology, things appear for subsequent technical progress but EVC does not even do this because its original idea is to create a codec from technologies that are no longer patented

I can envision designing a codec around solid and practical, mature principles, but it would still take some time before the encoder performs at the same level as existing competitors.

And then again for it to exceed existing competitors

Experimental software has to demonstrate function first before optimization

Well, this hasn't happened yet, I don't see any plans for this

like webp2

latest version vp9 with parameters "-crf 55 -deadline good -cpu-used 0 -aq-mode 3 -row-mt 1" gives better quality than av1 with identical encoding speed for first and third person games. Let me remind you that this is the limit of vp9, then comes the best preset which is equivalent to -1 (MR) av1 --- despite the fact that in my opinion vp9 has very bad PSY parameters. And obvious artifacts are noticeable. Technically, the quality and clarity are higher than those of the heavily smoothed AV1 in filters. And without filters at all, AV1 looks even worse

Encoding is bad.

That's about it TBH. I'm sure I could encode much better if you let me do it.

until my $50 smartphone can do AV1 MR preset in real time. We are doomed.

<:PepeSad:815718285877444619>

the point is that every are trying to use the AV1 codec to replace HEVC and VP9 with the same encoding speed and power costs. But this is a complete mistake. Only on presets that are the limit for hevc/vp9 and higher, av1 becomes the best codec

https://encode.su/threads/4408-brotli-encodes-26-faster-(lz-compression-tricks)

Does anyone have numbers on the decode speed of lossless JPEG92? I'm trying to figure out the impact of DNG compression and how it compares to JPEG XL, but can't find an easy way to encode/decode it

Lossless?

Had to dig up an old version of cjpeg someone had compiled, then use FFMPEG to decode the resulting file ``` 10bit Grayscale 3968 x 2976 Effort 7 Lossless AMD Ryzen 7 1700 JPEG92 4.82 MB speed=0.19x bench: utime=0.203s stime=0.000s rtime=0.213s JPEG XL 3.19 MB speed=0.34x bench: utime=1.766s stime=0.000s rtime=0.118s JPEG XL FD1 3.19 MB speed=0.59x bench: utime=0.734s stime=0.062s rtime=0.068s JPEG XL FD2 3.26 MB speed=0.72x bench: utime=0.703s stime=0.000s rtime=0.056s JPEG XL FD3 3.40 MB speed=1.26x bench: utime=0.422s stime=0.062s rtime=0.032s JPEG XL FD4 3.72 MB speed=1.35x bench: utime=0.422s stime=0.016s rtime=0.030s ``` Promising results. Simulating a 12MP bayer DNG it's up to 6x faster (On-par for singlethreaded), while still being 23% smaller

Good luck opening it

mpv displays it properly

FFMPEG backend if I recall?

yes

IIRC it is supposed to be grayscale?

Yeah

then yes, shows properly

It's a tiled RGGB bayer image

feh also works

nomacs and gwenview both fail

Do you get decode times? You could double check my results. This one is Faster Decoding 4

interestig, djpegli fails, but djpeg works fine

Is this lossless?

Yeah

What did you use to encode your image? I created a lossless JPEG one a few months ago and it opened properly in all of my image viewers. I presume the struggle opening this one is due to the 10 bit RGGB

The old cjpeg build I mentioned, and probably because I'm on Windows so nothing is using FFMPEG at it's core, other than FFMPEG itself which naturally worked

Can you try if VLC can open it?

I think that uses FFmpeg in the backend

at least for some files

Works for me with VLC

Yeah that works, it has FFMPEG as fallback. I always forget it can open images

jpegli has the bare bones 'Internet Spec' for now, it's missing anything slightly exotic like arithmetic and lossless

You just used ffmpeg with "-benchmark"? Or anything else I should include?

Pretty much `ffmpeg -hide_banner -benchmark -i Test.jxl -f null nul`

``` JPEG92 speed=0.354x bench: utime=0.109s stime=0.004s rtime=0.113s JPEG XL speed=0.859x bench: utime=1.235s stime=0.023s rtime=0.047s JPEG XL FD1 speed=1.71x bench: utime=0.483s stime=0.063s rtime=0.023s JPEG XL FD2 speed=2.21x bench: utime=0.407s stime=0.010s rtime=0.018s JPEG XL FD3 speed=3.89x bench: utime=0.149s stime=0.007s rtime=0.010s JPEG XL FD4 speed=4.4x bench: utime=0.126s stime=0.009s rtime=0.009s ```

Huh, I wonder why yours are so much faster than mine

Probably because my CPU is much faster, I have a 7950x

It checks out

Let me test something rq

I was going to ask what cjxl version you used for the other faster decoding files, but if it was old then you'd have some very weird results before our PR

On an RPI4, FFmpeg version 5.1.6-0+deb12u1+rpt1: ``` JPEG92 speed=0.0785x bench: utime=0.485s stime=0.028s rtime=0.513s JPEG XL speed=0.0551x bench: utime=2.529s stime=0.204s rtime=0.727s JPEG XL FD1 speed=0.0904x bench: utime=1.389s stime=0.220s rtime=0.444s JPEG XL FD2 speed=0.0968x bench: utime=1.274s stime=0.216s rtime=0.414s JPEG XL FD3 speed=0.118x bench: utime=0.949s stime=0.246s rtime=0.340s JPEG XL FD4 speed=0.121x bench: utime=0.865s stime=0.285s rtime=0.332s ```

I used the post-PR version you linked a few weeks ago

Would be funny to test on increasingly slower and slower devices

Maybe someone has an RPI3 or even older lying around? Maybe a Pi Zero?

<@184373105588699137> did tests on a HP compaq mini https://quackdoc.github.io/blog/hidden-jxl-benefits/

(That page locked up my browser due to the Oxide extension again... Maybe I should disable that sometimes)

I *do* have an rk3188 machine too, but I havent managed to get it to work by flashing the storage, the dtb is buggered up. Microsd card booting does work on it but it's too slow, I can install termux on the native android, no idea but that probably wont be a proper test

Where did you get that extension? Quick search gives me no results

its a backed up version of the jxl-crx extension. The dev had a jxl-oxide branch but sadly the entire repo was nuked

mv2 and mv3 versions

Thanks

I edited mine to set the blob type to PNG

can source and extension be rehosted on github? sure the commit tree would be missing but that could help efforts for a new user-installable extension (xpi distributed from github, not mozilla/chrome addons)

odd repo was gone. i think its dev is still active online though and just hasnt explained nuke

I mean, if someone can find the commit they can just punch it in, I don't remeber it sadly

> The source code for versions prior to 0.2 can be found here: > https://web.archive.org/web/20231223101411/https://gist.github.com/zamfofex/e6e0109862e5da8e7f6fa634b1ceca26

v3 is here fwiw https://github.com/FOSS-Archives/jxl-crx

<@98957339243073536> if you're bored....

random noticing: almost 5000 (current) users intentionally went out of their way to install that jxl extension

I have an RPI3, lemme dust it off real quick.

Intel i5 12400``` JPEG92 speed=0.306x bench: utime=0.125s stime=0.000s rtime=0.131s JXL speed=0.383x bench: utime=1.016s stime=0.000s rtime=0.105s JXL FD1 speed=0.663x bench: utime=0.516s stime=0.000s rtime=0.061s JXL FD2 speed=0.752x bench: utime=0.469s stime=0.000s rtime=0.054s JXL FD3 speed=1.47x bench: utime=0.203s stime=0.000s rtime=0.028s JXL FD4 speed=1.52x bench: utime=0.203s stime=0.000s rtime=0.027s ```

I wonder what is faster, the rpi or the rk3188, tempted to try it now and see

RPI 3B+``` JPEG92 speed=0.0337x bench: utime=1.151s stime=0.048s rtime=1.199s JXL speed=0.0237x bench: utime=6.111s stime=0.337s rtime=1.700s JXL FD1 speed=0.0418x bench: utime=3.141s stime=0.368s rtime=0.971s JXL FD2 speed=0.0452x bench: utime=2.868s stime=0.357s rtime=0.899s JXL FD3 speed=0.0541x bench: utime=2.173s stime=0.477s rtime=0.754s JXL FD4 speed=0.0575x bench: utime=2.022s stime=0.459s rtime=0.711s ```

Really shows how slow and inefficient the Weighted predictor is, almost twice the CPU time just from that. FD1 only disables WP

It is heavy compared to any of the other predictors, but for photographic images, it is the best single predictor we have. Plus it has some untapped potential since it has parameters that can be adjusted...

Yeah, it has it's place, hopefully there are ways to speed it up in future. Right now, Weighted is always assumed in the MA tree learning, even when forcing specific predictors. So it skips the fast decode path unless the new FD1 or effort 2 is used. Might be an easy way to boost decode speed if we check that the current predictor isn't 6, 14 or 15 (WP, WP+Gradient, All) and then set the tree type to kNoWP

That does come at some small cost in density though, since even when not using the WP as a predictor, it may be useful to use its property in the decision nodes (which means you have to maintain the WP state anyway)

I thought the property can only be referenced when the predictor is used? Seems I might have to read the spec again

Just did a comparison against PNG too. With Faster Decoding 4, singlethreaded it's around 3x slower, but multithreaded it can be over 2x faster ``` 8bit RGB 7680 x 4320 Effort 7 Lossless AMD Ryzen 7 1700 PNG 27.8 MB speed=0.09020x bench: utime=0.422s stime=0.031s rtime=0.444s JXL 1t 18.6 MB speed=0.00512x bench: utime=7.734s stime=0.062s rtime=7.806s JXL 1t FD1 19.1 MB speed=0.00975x bench: utime=4.078s stime=0.047s rtime=4.102s JXL FD1 19.1 MB speed=0.09380x bench: utime=5.969s stime=0.062s rtime=0.427s JXL 1t FD4 23.6 MB speed=0.03350x bench: utime=1.172s stime=0.016s rtime=1.194s JXL FD4 23.6 MB speed=0.21900x bench: utime=1.828s stime=0.172s rtime=0.183s ``` Went for a bigger image for more consistency and clearer results

10x multithreaded speed difference? How many threads?

16

Yet not a 16x increase...

Well yeah, it's only hyperthreading past 8

perfect parallelization is hard anyway, there's almost always something sequential left or some memory bottleneck

Yeah. Linear scaling is a really impressive and rare achievement.

I wonder what the scaling is for 8t on your machine

IIRC it scales linearly up to around 4 threads, then starts to taper off

Likely depends on the image, effort, and other settings too. Since more threads doesn't do much without groups to use them

Which reminds me, I can't remember if I tested this or not https://github.com/jonnyawsom3/libjxl/tree/Group-Threading

Interesting. Commons seems to have random fullcolor GIF encodes that aren't actually used anywhere https://commons.m.wikimedia.org/wiki/File:Juncker_2010-GIF-Truecolor.gif

<@1156997134445461574> apologies for the ping once again. Do you have any idea if the empty 14 byte EXIF that gets added to all images on upload is an issue with Discord, lilliput or piexif? I know while adding animated WebP support, you already found some bugs in the latter, so it could be a relatively simple fix to save some data for free and avoid bugs in other programs trying to handle a blank EXIF. > Discord has historically relied on the piexif Python library to strip EXIF data from media files. However, we discovered that bugs in piexif were corrupting WebP metadata during the EXIF removal process

Honestly, I'm surprised no one here has asked you before. It's been an issue for years now and has caused a few problems, especially when trying to compare filesizes, since it means JPEG XL has to use the container format instead of the bare codestream *along* with storing the blank EXIF itself

damn, he's gotten fat

and old I guess

``` 8bit RGB 7680 x 4320 Effort 7 Lossless AMD Ryzen 7 1700 cjxl -d 0 --faster_decoding 4 ffmpeg -hide_banner -benchmark -threads 1 -i Test.jxl -f null nul JXL 1t FD4 speed=0.0314x bench: utime=1.250s stime=0.016s rtime=1.275s JXL 2t FD4 speed=0.0577x bench: utime=1.359s stime=0.000s rtime=0.693s JXL 3t FD4 speed=0.0826x bench: utime=1.359s stime=0.031s rtime=0.485s JXL 4t FD4 speed=0.1060x bench: utime=1.359s stime=0.031s rtime=0.379s JXL 5t FD4 speed=0.1280x bench: utime=1.469s stime=0.031s rtime=0.314s JXL 6t FD4 speed=0.1490x bench: utime=1.516s stime=0.000s rtime=0.269s JXL 7t FD4 speed=0.1670x bench: utime=1.453s stime=0.062s rtime=0.240s JXL 8t FD4 speed=0.1790x bench: utime=1.469s stime=0.047s rtime=0.224s JXL 9t FD4 speed=0.1840x bench: utime=1.547s stime=0.062s rtime=0.218s JXL 10t FD4 speed=0.1940x bench: utime=1.750s stime=0.000s rtime=0.207s JXL 11t FD4 speed=0.2040x bench: utime=1.859s stime=0.016s rtime=0.197s JXL 12t FD4 speed=0.2130x bench: utime=1.875s stime=0.031s rtime=0.188s JXL 13t FD4 speed=0.2190x bench: utime=2.062s stime=0.000s rtime=0.183s JXL 14t FD4 speed=0.2240x bench: utime=1.688s stime=0.062s rtime=0.179s JXL 15t FD4 speed=0.2320x bench: utime=1.984s stime=0.047s rtime=0.173s JXL 16t FD4 speed=0.2380x bench: utime=2.031s stime=0.062s rtime=0.169s ```

I now realise it was FD1 that had the 10x scaling in the other test, but I spent an hour on that monolithic wall of speeds so oh well

At some point I'll consolidate the results and post them to <#803645746661425173>

<:logo:829708783336816671> <:Thonk:805904896879493180>

The RK3588.

not 3588, 3188, or rather specifically the RK3188T

Quad core Cortex-A9 1.4GHz don't be mislead though, these may be a9 cores, but man are they downclocked and first gen

the A53 is actually quite a bit faster then the A9 at clock per clock, but I has 4gb ram and 1.4ghz (if they have the rpi3b+ I loose for sure)

😭

I still havent gotten linux to work natively on it due to I think the dts not being proper, I can boot into initrd so I *can* install linux as an image like that however

no time

How is the LF image encoded in JPEG92?

Fixed West predictor, single context (Huffman code) for all LF, though iirc you can effectively have different contexts for msb vs lsb by doing multiple progressive scans.

can LF be done with multiple scans? I forgot the details after writing reconstruction in jxl-oxide...

In JPEG, you can have DC scans per component and range of bit positions. In JXL, you can use an LF image which can itself be as progressive as you like. If the LF is part of the frame itself, it's just a single pass.

Seems like an obvious missed opportunity that the jpeg92 image cannot be recursive

But I was more curious about what the precision is for encoding the LF image

Google hierarchical JPEG

JPEG Photographic Experts Group

Hierarchical JPEG is basically JXL progressive lossless

The 1992 spec did have a mode called Hierarchical JPEG, it just wasn't implemented in libjpeg so never became part of the de facto format.

From <https://github.com/thorfdbg/libjpeg> > -y levels : hierarchical JPEG coding with the given number of decomposition > levels. If levels is zero, then a lossless coding mode for > hierarchical is used in which the second lossless scan encodes > the DCT residuals of the first scan. For that, -c is suggested > for true lossless. If levels is one, then the lossy initial scan > is downscaled by a power of two.

But I'm not aware of anything than could decode them, other than the example program it has. FFMPEG shows... Something...

I meant the original IJG libjpeg, which kind of defined the de facto format (and later got forked to libjpeg-turbo). Thomas' libjpeg is more recent and it's the first one that is actually completely implementing the 1992 spec.

Oh, I must've overwitten my message without realising. I was going to say, even less common and non-de facto things like arithmetic or lossless tend to work for specialty situations. Hierarchal seems to be only implemented in the modern libjpeg and not accepted anywhere. Though I suppose there's web spec, de-facto spec and full spec

<@132186538325835776> found your tool being used in the wild: https://brickadia.com/blog/feature-preview-1/#:~:text=to%20AVIF%20using-,this%20tool%20i%20found,-%2C%20so%20they%20can

nice

brickadia :woag:

the only program that I could open this image with was Windows Paint. And the image is BMP. No one wanted to open it in PNG anywhere. But the python library imageio was able to open it for work.

What is this. Why is it so large

happens :)

the important thing is that the problem of opening such images is not technical, but software, standards in order not to comply with them. or to be more precise, the programs are so crookedly written and so poorly technically implemented that it just cannot open such images. although it uses only 30 mb of ram

Does cjxl handle that file without crashing?

I'll check it out in 20 minutes

Probably it needs a lot of ram

Just look at it. windows background decoded 1.5 million pixels width to create the cover. Is Linux really able to do this?<:Poggers:805392625934663710>

<:Poggers:805392625934663710>

You'd probably want to do PPM input streaming

are you saying that cjxl just won't open png? Why?

bruh

bruh 2

yep. 400 mb ram use

How do I open it? I don't know. literally a JXL bomb

great

paint net has also opened bmp and JXL but cannot open png... just like that. At the same time, for cjxl must be converted to ppm. Why?

And it's all about computers, how I hate computers.

I think this is a great file to check programs for how well they follow standards

Uncompressed PNG + Brotli, not practical but fun

That's not using input streaming, but I guess it works

Input streaming lowers ram usage to 40 MB for me

is use of dav1d universal in the apps and website? like, overriding whatever system/browser library you have installed

seems like it well tbh idk but phone and laptop support AV1 yuv420 8bit & 10bit from what I tried

android will likely be dependant on the phone itself for the older apps, for the newer apps I dunno, too sick to unpack the apk lmao

That looks like lossless webp. Where does that diagram come from?

what server is this from?

Av1 community

Big news: PNG spec 3rd edition is a W3C recommendation from today https://www.w3.org/news/2025/portable-network-graphics-png-specification-third-edition-is-now-a-w3c-recommendation/

APNG is finally a standard after 20 years

Very nice

<:Yes:1368822664382119966>

<:PepeHands:808829977608323112>

Twitch thought about it and decided, no AV1 and no VP9, ​​we are switching to a proprietary codec that not everyone supports, and which has NEVER been an internet standard yammy (hevc)

How many years before HEVC is finally not patent encumbered? 10?

yep. make hevc great again only in 2035

even AVC has patents until 2030

considering AV1 is dead and AVC has been use for 20 years i dont think we should worry about it we are stuck in a trap of no progress

a much bigger innovation is that twitch ALLOWED to send all quality variant stream that the streamer will render themselves. This increases the load on the streamer, but greatly increases all video quality options from 720 to 160. Just because twitch equipment is cheap crap

Baseline spec is from 2013 so in 2033 it should start becoming available. Extended profiles maybe later, I dunno

<@703028154431832094> I know you're busy working on the tests in <#803645746661425173>, but as the resident AV1 guy, I wanted to ask you how I can use FFMPEG for things like SVT PSY or AOM Tune IQ. As far as I can tell, AOM with IQ is best for AVIF, and SVT PSY is best for video, but I know a lot of PSY has been merged into the normal encoder, so I'm not sure which I should use or what parameters I should pass to them. Thanks in advance, I'm sure you get this pretty often

i think you'd probably be better off using SVT-AV1-HDR now instead for video: https://github.com/juliobbv-p/svt-av1-hdr/

as for aom, I'd use libavif for that, and just pass the arg `-a tune=iq`

<:SadCheems:890866831047417898> i hate PSY (technology). i turn it off in AVC/HEVC, and i hate it in VP9 <:VP9:981490623452430376> in AV1 a filter with similar properties is called a temporal filter (tf), it is mandatory to disable <:AV1:805851461774475316>

because we live in a world where most videos are not viewed at the pixel-to-pixel resolution of the monitor. And lower resolutions are viewed on a larger monitor. PSY and Trellis Quantization technology, are the scourge of codecs, causing many more visible artifacts than would be the case if the quality dropped a little.

the Trellis Quantization analogue in AV1 is called "enable-qm" and I also recommend disabling it

BTW <@238552565619359744>, if you're using SVT-AV1-HDR, defaults are good enough for general-purpose encoding

use `--tune 0` if you prefer a bit more sharpness (at the expense of metric performance), and `--tune 3` for grainy video

Do they not take resolution into account?

Currently using this with Preset 8. I'd have liked to go slower but it's barely hitting 1x encoding speed, I assume it also has tweaked defaults? https://github.com/Uranite/FFmpeg-Builds-SVT-AV1-PSY/releases

yep, -PSY has tweaked defaults as well

if you can tolerate preset 6 speed, I'd highly highly recommend it

the visual quality improvement over 8 is immense

https://www.programmax.net/articles/png-is-back/

Oh the author is also the chair of PNG Working Group

👀 > I know you all immediately wondered, "better compression?". We're already working on that. And parallel encoding/decoding, too! Just like this update, we want to make sure we do it right.

So the greatest competitor of JXL in the next decades will be... PNG!

https://www.reddit.com/r/webdev/comments/1lj81pc/png_is_back/ > The method PNG uses for compression is nearly the same as the method used in lossless webp and jpegxl. Those formats are newer and benefit from modern improvements. But under the hood, they work in mostly the same way.

Is that true?

I'd say png can do strict subset of jxl

He admires JXL however > And of course, JPEGXL is amazing. I'm hoping it gains wider support.

'consumes no extra storage for hdr' isnt as compelling as some think (cue 'ultradhr'). lossless jxl consistently weights half a png wether its true hdr, gainmap hdr or sdr

especially on mobile, where people are consistently starved for storage and images only keep getting bigger

Users complain about prices first

Hmm the chair built that blog simply for telling people PNG is back

A rough roadmap is also revealed > We expect the next PNG update (Fourth Edition) to be short. It will improve HDR & Standard Dynamic Range (SDR) interoperability. While we work on that, we'll be researching compression updates for PNG Fifth Edition.

Oh great it's JPEG and AVIF all over again. Extensions and updates added that break compatibility and old decoders, so no one will bother to use them

at least the PNG spec has dedicated spots for incompatible new compression methods and new delta filters although they have always been marked as being for future reserved use which means no one can agree on what they would equate to

So instead of trying and failing, now decoders will try and error... Not much better, and that's assuming the past 20 years anyone has actually put in handling for the reserved values instead of hardcodinf Deflate and the current filters

https://github.com/w3c/png/issues?q=label%3Abackwards-incompatible

for psy? i don't know about that. vp9 takes into account the resolution for block splitting

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1555914-png-spec-updated-for-hdr-images-animated-pngs

what about tune 2? and isnt tune 0 the default in the handbrake fork

I don't control what handbrake defaults are, so I can't really comment on those

but tune 2 is a good general-purpose tune

you can switch to tune 0 if you find encoded output too blurry

good to know

bruh what really?

how did they not add associated alpha 💀

pretty sure they still think associated alpha is purely an optimization to save a little math when loading an image file

what's associated alpha?

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

('associated' here means premultiplied)