JPEG XL

leave only the eyes. you can use mine <:Poggers:805392625934663710>

eyeballs best metric kek

tune=vq xD

There is no need for metrics here, though. The fading can be seen with the eyes.

you know, fading is not the only problem that no one else has, but only jpeg xl has...

It was working well in 0.8 though, and the PR only changed how the AC is calculated

jon has explained to me many times what this is. But I still don't understand why they can't just fix it. These are artifacts outside the block being coded.

iirc that is also a problem with av1

causes significant banding iirc

this is not the problem, you thought that it is in one block, but no, these are different unrelated blocks

ahh right right nvm

https://discord.com/channels/794206087879852103/848189884614705192/1069924982571933756 the problem is that as <@238552565619359744> https://discord.com/channels/794206087879852103/805176455658733570/1392641838216908952 said there is a 32 bit float. But as it turned out, if you look at this float, it goes further and further, it penetrates through other blocks generating artifacts

the anomaly is that if there is at least 1 pixel of the color inside the block that causes artifacts, then there will be no artifact, here it is visible in green below

https://cdn.discordapp.com/attachments/794206170445119489/1210512361048248320/jxl_animation.gif?ex=68702abd&is=686ed93d&hm=359167650fe657f0eced39608a54ec75743c4bd3ea33930bea4d38116f01e6f7& fading, which depends on the quality of UV (color) is clearly

please note, the image, that is YUV full, Y looks great, even on d 2 --- but the UV color channel https://discord.com/channels/794206087879852103/805176455658733570/1392641512474677319 at the same quality looks simply disgustingly compressed.

XYB..... ohuh

this sounds like a solution... and now all jpeg xl images will have a separate table for XYB just to keep compatibility. Just great

although maybe I didn't understand which tables exactly. In any case, it all looks like you just need to redistribute the importance of coding in XYB. But how to do this for UV which does not exist in the XYB world. Well, good luck

there is clearly some fundamental flaw here that was made during the design and was not noticed later

webp is the only format that does not fade even on q0.

all of this could be used to make a great article in the style of **"10 years of development and nothing is ready with a description of all the global problems and why you should never use jpeg xl"** it's a pity that no one wants to interview me <:KekDog:805390049033191445>

"the newer the encoder the worse the quality, use the oldest one" <:Xjxl:822166843313225758> ☝️

The quant matrix can be stored as parameters instead of a table, an equation. A simple maths formula only a few bytes long for possibly significant improvement with the saturation

👍

If you told me what exactly to look for and what the formula might look like and how to apply it. I might even be able to look for a better quality formula for this, find

but for now it sounds like "there are no tools"

avifdec upsolutely does proper interpolation when upscaling chroma, as I said before

Yes, afaik that's what browsers do with YUV 4:2:0 video, they scale the planes independently to target resolution, using bicubic for luma, and bilinear for chroma, only then convert to RGB. Interestingly that's not at all how most other software solutions do it, where chroma is upscaled first, and scaling is usually done in RGB (rarely linear RGB sadly).

wait, what fact did you confirm?

the aomenc ssime tune doesn't even use ssim, it's just the psnr tune with variance-based offsets tuned for ssim and the butteraugli tune ran actual butteraugliy on every superblock, but never even worked properly anyway

What weird methodology would produce similar efficiency results for HEVC and AV1, but way better ones for VVC?

I think this is the BBC test from 2019

https://www.bbc.co.uk/rd/blog/2019-05-av1-codec-streaming-processing-hevc-vvc

avifdec does not interpolate. I see that in XnView and PainDotNet the color is scaled by the nearest neighbor. That is, natively this is raw data and avifdec does not make any interventions. Because AVIF is AV1 and AV1 is a video codec, the video is played in video players that do interpolation themselves, and photo viewers do not do this natively at the color level, unless they are configured to do this in advance, which depends only on the software. I see that AVIF does color interpolation, for example, if I open a photo in MPV. While WEBP is VP8 But WEBP is an independent format, so they decided to do interpolation natively in the decoder, because no one watches WEBP in a video player

I think you can compress 100 random videos and find the exact moment when a similar situation occurs by cutting out 10 seconds of the video. I don't care. It's almost a meme.

> avifdec does not interpolate. Then it means Paint.net and XnView don't use avifdec. How about you actually use avifdec directly and see for yourself instead of spreading misinformation?

Good point. But here's what I'll say: at the moment when, in order to prove whether the UV color layer is interpolated, I have to check what specific decoder is used there, and what specific decoder parameters are used in each individual program. -- I don't give a shit I see that there is no interpolation there, why do I need to check anything? Here it is, here it isn't. compiling a list of programs with what specific decoders they use, and what possible parameters are set for these decoders by the program developers themselves, of which there are dozens, is an exorbitant amount of work. I will not do this.

It's fine if you don't care enough to put in the work. Just don't spread falsehoods when you don't know.

Well, the accusation of lying is also without evidence. So don't accuse me of spreading lies until you prove otherwise, until you show that I'm wrong.

"misinformation"

for now I live in a world where** i should** to manually interpolate AVIFs before working with them in paintdotnet because it doesn't do color interpolation itself. That's the world. But Webp does, and it's easier to work with than AVIF because of that.

Left is Paint.net right is avifdec. *Misinformation - incorrect or misleading information.* My use of the word is justified. Don't make claims without double checking your work. What's wrong with simply saying, "Sorry I was wrong."?

Avifdec always properly interpolates. It properly interpolates if you request RGB, and there's nothing to interpolate if you request the original YCbCr. Maybe some software uses years old avifdec versions? But anything from the last 2 years should be fine.

If the image viewer decides to interpolate itself and fucks it up, it's hardly the fault of avifdec. How do you know whether mpv uses avifdec to request RGB, or requests YCbCr and interpolates the chroma itself from 4:2:0?

XnView and paintdotnet request RGB interpolation no Video request yuv and interpolate self

libwebp also allows to request either raw YCbCr or RGB, just like libavif

lossy webp is a vp8 keyframe, avif is an av1 keyframe

I don't see a relevant difference

you want me to say that av1 in paint and Av1 in terminal decoder are different things i won't do that because it's stupid

if they request RGB from libavif and it doesn't properly interpolate chroma, it must be an old broken libavif version or they explicity request nearest neighbour upscaling from avifdec, which is an option, but default is bilinear

xnview 2025 paint 2024 why are these even arguments. the format is 7 years old

there have been many problems with AV1 software 🤷 not denying that

"maybe AVIF is so unneeded that the interpolation problem was only natively noticed 6 years later"

took them 6 months to notice, lol: https://github.com/AOMediaCodec/libavif/issues/1475

wild

<:kekw:808717074305122316>

anyway, if a version from that timeframe is used, it might be responsible for the issue you're seeing

real shit

ok, i believe

Looking at the source code, libavif uses libyuv to interpolate it's chroma, but it seems that paint.net's avif plugin doesn't use libyuv, which could explain why it doesn't interpolate chroma planes. How interesting.

<@833420862334042152> Since you are the creator of the plugin, is my theory correct? Here is a visual example: https://discord.com/channels/794206087879852103/805176455658733570/1392964573593735190.

The Paint.NET plugin does not use libavif or libyuv, it uses AOM directly with YUV<->RGB conversion code that I borrowed from libavif.

It would be nice to have simple bilinear upsampling for subsampled avifs, the aliasing is quite bad. Do you plan to fix this issue?

> i won't do that because it's stupid What's stupid is ignoring evidence, because what I said is proven true. 💀

No.

libyuv looks complex to use, plus it is only 8-bit.

How does lossless jxl compare to lossless png?

It depends on your contents

If your images are greyscale screentone mangas, PNG is often smaller than JXL with `cjxl -d 0 -e 10 -E 4 -I 100 -g 3`

Generally, around half the size

sorry for the fact that paintdotnet uses not av1 (avifdec) but av1 (aom), I was wrong

disgusting. nobody wants unsmoothed colorspace pixels

As I stated in my reply, libyuv looks complex to use and only supports 8-bit.

I don't understand the meaning of this sentence. Let's start with the fact that paintdotnet has 8 bit color. It doesn't support 10 or more. As I understood from your answer. Just aom library decodes without interpolation. But for color interpolation flag, key like ? https://github.com/AOMediaCodec/libavif/issues/1475

if AOM does nearest neighbor interpolation in yuv -> rgb, I don't see a problem with at least doing bilinear

1. High bit depth images are handled by the Paint.NET AVIF plugin. Currently it converts them to down 8-bit, but that will change if/when Paint.NET gets support for > 8 bits-per-channel. 2. I am using my own decoding/encoding code, so the libavif options are irrelevant for the Paint.NET AVIF plugin.

https://www.androidauthority.com/android-canary-hdr-settings-3576420/

powered by that revolutionary Ultra HDR

👌

another question I thought of: 5. are there any plans for creating/encoding animated WebP files? either in a basic way where it just stitches multiple static Iris encodes together or something more advanced like trying to consider blending and whatever else between frames? I assume this would probably be a low priority thing/feature but I'm just wondering if it's even something that is considered at all.

something like a "would be a nice extra to have in the future" would be fine

animated webp is supported currently

for platforms with a lot of UGC, I think animated WebP becomes non-optional to support

is there any logic or tune-ing in Iris for when and where to do keyframe insertion? iirc libwebp is very bad in this regard (at least by default though I haven't fully looked into it)

honestly, not right now – that'll be something to look into

Very impressive.

😳

On giant images like 4000x4000 Guetzli also suffers from noticeable fading… Yet a much more serious issue is that on lines and text—areas that are highlighted as Guetzli’s strengths in the original documentation—it produces far worse results than MozJPEG at the same file size. Paradoxically, I just want to state that fact. The only place where Guetzli wins, because Butteraugli metrics, is in smooth gradients and dark regions. Everywhere else it’s a complete failure. I’ve tried Guetzli only a couple dozen times since its release and never ran formal comparisons until now. Wow, JPEGli, Guetzli and this whole psychoacoustic approach are objectively poor, which is somewhat at odds with the hype. Apparently people care more about smooth gradients in JPEGs than about preserving fine detail. From all this—for charts, text and graphic designs, if you have the original source—you’re better off using MozJPEG. For everything else, it’s up to you. What really frustrates me is that in situations where per-pixel informational fidelity is critical, PSNR still wins out, not these next-generation algorithms. They solve some problems but create new ones; it’s not just an enhancement, it’s a fundamentally different algorithmic paradigm. it doesn't have the advantages of the past method. This is all so annoying... panacea that breaks the global coefficients The problem with finding the effect is that it is most noticeable on large images that contain a large number of elements. Guetzli is engaged in the selection of global coefficients. In the case of a separate image, it is really difficult to say that there are problems. But if the image is part of a larger picture, with identical parameters it suddenly becomes disgusting. With a large picture, mozjpeg gives much noticeably better quality with the same image size. And I can't say why, I just see that it is so, and it irritates me. I think there are no problems if the Guetzli picture is not large crop of original | mozjpeg | Guetzli

So guetzli works better on small images than mozjpeg?

On q84 no. On q90 we can say that in the total number of artifacts they are equal. In the presentation documents there was a comparison on test images with q95 quality. And on this quality it demonstrates an advantage... (Honestly, it is similar to comparing mp3 320 kbps with opus 320 kbps. While opus has fundamental problems because of how it works, mp3 can do better at this bitrate and transmit a more accurate waveform than opus.) Comparison of these two codecs is also important because of the selected image for tests. If there is some wildlife, sky, noise of leaves due to interpolation. mozjpeg saves a lot of unnecessary. While guetzli does it better, because small details are not so important, but the overall picture. But in cases when these are arts, text. Well, as I wrote earlier, mozjpeg can be better. It's all confusing because I can't just say: guetzli is better, use it. Because it turns out that it's not, and it's not a panacea.

I would really like to say that guetzli is like a placebo preset. But it is absolutely not, it is a completely different way

it's weird that no one has invented a combined quality metrics algorithm. for example Butteraugli for low frequencies, PSNR for high frequencies, I think that would be perfect <:bayer:1284515744981450824>

actually...

butteraugli itself is relatively similar to that idea but opposite

low frequency is almost only used in a simple L2 diff I believe in butter

I see that the high frequencies are changed quite strongly in guetzli, in favor of the low frequencies. But globally it looks worse in a large number of situations

I am speaking about butteraugli inner working

your idea will not work

/ doesnt not make sense

well i dont have the ability to just select butteraugli in mozjpeg or webp. to make comparisons with guetzli and jpegli

if you wish to change that there is an "hf_asymetry" variable inside

which controls the hf/lf balance

butteraugli is great ^^

"something in the language of programmers"

you want to create a solution to a problem, I offer you solutions

I like compression, but the work on the svt-av1 fork is enough for me not to go back to it anymore

no more coding and compiling

this statement doesn't quite match reality, if it's so good, why isn't it available anywhere? webp av1 avif vp9 avc hevc -- it's not built in anywhere by default.

simple: it is a very heavy metric

expensive to compute

ssim yes. Butteraugli no.

SSIM is super simple to compute

everything is about a compromise of quality and speed

butteraugli is on the quality end

ssim on the speed part

I know because I compiled aom with Butteraugli but that's not the question - why isn't it built in by default, as an option, as a test, as a debug. If it already exists for AOM as a separate key, why isn't it by default?

PSNR is speed without any quality ahah

because it is slow

I only ever saw usage of butteraugli since I implemented it on GPU

because only then it started being actually usable for video tests

absolutely not. there are many situations where PSNR will be better than SSIM

I do not agree but both are bad anyway

they are both speed metrics

PSNR is litteraly just L2 norm lol

Butteraugli fan vs PSNR enjoyer

PSNR is just... not even a reference because it is so bad for psychovisual comparisons

it has litteraly **nothing** psychovisual

Butteraugli is not so complicated that it should not be embedded at all. This is all somehow wrong. GOOGLE is waiting until 2040 to add Butteraugli to webp I'm sure... Wait, can Butteraugli work with YUV420?

Butteraugli requires changing to XYB colorspace

"Butteraugli is not so complicated that it should not be embedded at all."

what makes you think that?

on any high end pc with the AVX optimized jxl butter, you only ever get 8 fps

on an RTX 4080 super you get about 150+ fps

but you can't use the gpu inside the encoder because of latency

at least with current encoder designs

Well, yes, that was about the same... I feel even less

this is pretty sad ahah but yes

The thing is that in the real world, everything ends up looking like this: the metrics are important, of course, but the compression algorithms overshadow their influence too much. my tests AOM (in 2023) Butteraugli | SSIM

Butteraugli is certainly better. But is it worth it... When it is much more profitable to increase the complexity of the quality preset by a few points and get better compression quality, compensating for the imperfection of the metric

ooh well butteraugli is too expensive, I also believe it cannot replace PSNR and SSIM for every encoder internal tasks

butteraugli for libaom is just an experiment that is not even fully utilized and not fully integrated

aom built with Butteraugli in 2023 for windows reconvert `ffmpeg.exe -i "test.mkv" -vf "scale=960:540:flags=spline" -pix_fmt yuv420p -vsync 0 k.yuv` and do this `aomenc.exe --cpu-used=8 -h 540 -w 960 k.yuv --tune=ssim --output=test.ivf` `aomenc.exe --cpu-used=8 -h 540 -w 960 k.yuv --tune=butteraugli --output=test2.ivf`

since there is just does not exist this for windows, this is a great artifact

on Intel(R) Xeon(R) CPU E5-2666 v3 @ 2.90GHz processor the Butteraugli speed was 1.6 fps/s

monothreaded? 😨

I'm not sure, although it's still aom and not svt-av1

I remember it was so long that I told my friend to stop doing it, it was so long, but here are a few dozen frames for comparison. Maybe it will be useful to someone

well, it makes sense if you do "source" style video compression on preset -1 and Butteraugli. It was just "the best thing you can do with this codec"

It was too slow to gain any traction.

in 2025 technology has only just reached the point where it can use HEVC without cutting technology

PSNR is popular because it's very simple to compute (just sum the squared errors), but it is not a perceptual quality metric, i.e. something meant to evaluate the quality of lossy compression, it is an error metric for things like noisy communication channels where the noise is not the result of some perceptually motivated lossy compression method, but just some independent error during capture, transmission, or delivery.

PSNR SSIM and other methods were really bad when I made the algorithm for drawing ASCII letters. I went calculated the error by comparing the difference of all pixels in the block. This turned out to be the best metric. Although not psychovisual, but absolute

funny that there are no other popular fast alternatives, no competition. Everyone just accepted that there is psnr ssim and that's it. Everything else is too complicated

It is easier to optimize for something simple than to solve the actual problem. It's the classic thing that tends to happen in both academia and industry: if the real problem is messy and hard, the problem just gets redefined to something that is more convenient to study or engineer for.

"There is no time for innovation, it's time to make capital" <:Stonks:806137886726553651>

My special keys for HEVC encoding have stood the test of time so I even decided to give them the name **EASYHEVC ** — because the main feature of the output hevc file is the decoding speed, which can be 2-3 times faster than standard HEVC parameters, which makes it similar to VP9 in terms of decoding simplicity While combining all HEVC technologies to the maximum. Basically, I did this to save stream twitch recordings in the telegram, so that it would take a minimum of energy when decoding, without discharging or heating smartphones, and at the same time 1280x720 60fps could be played without problems on any smartphone even 8 years old. Also preserving the full legacy for the hardware decoder of even the very first hevc of 2013. > In general, this is my fundamental work with testing absolutely every possible parameter that can be set in x265. And these are its results. I use crf 26 as a standard, ideal that I found, no artifacts, but no unnecessary noise either. To use bat, place the latest ffmpeg.exe with it in the folder and drop the file for encoding into the .bat file The only thing is that the sound in the file must be in stereo tracks and 1 track, or use audio copy.

plz just let mp3 die gracefully 😆

mp3 is dead... the whole internet uses opus. But mp3 320 just doesn't make sense to die. It's too good, it's enough, While AAC and Vorbis are trapped by the maximum bitrate, which can exceed the bitrate of the original Flac file. MP3 has a great argument - here are 320 kbps and that's the maximum, you don't need more. And it sounds just great. Same as using jpeg for Q98. No problem. lame.exe -q 0 -b 320 completely solves any problems.

I myself use mp3 320 to release tracks that will only be in a single copy. For personal music storage for 5 years , I have been using OPUS 128 if the source is mp3 320 and OPUS 160 if the source is Flac

i use MP3 a lot still

just because i have an old mp3 cd player that I still burn stuff to

the way

missing only one thing that needs to die there, mp4 xD

a couple of years ago i had headphones with sd card inside, built in player in headphones and it only supported mp3. Although this device is from 2022

if someone made a CD player that suppored Opus files burnt to a disc then I would stop using MP3

mp4 is great. it's just different way than mkv/webm

me when my "header" is at the END OF THE FILE

:)

it's pain, with no workarounds when it fails

granted it's ancient so those instances are rare but when u hit em ur sol XD

Fast-start MP4 is okay

but non-fast start MP4 can go die in a firey pit of hell

yea thats about the only thing ill give mp4, fast start is handy

but MKV can also fast-start

the header is always... at the head of the file

the only thing at the end is the seektable

so a truncated file is still playable, just seeking is slower

actually exists the blocks mp4. fragmented mp4. But in order to encode something, just use mkv, I don't see any problems with that. mkv is too redundant a format, it is gigantic, huge, its documentation, its capabilities. That is why Google created WEBM, which is a very cut-down mkv. In general, we live in a world in which you can't encode hevc in Webm because welcome to the format war. In mp4, recently you CAN encode both av1 and opus and vp9, which I actively use in telegram. I have been using opus in audio tracks for 4 years now

the reason why you can't encode (or technically mux) hevc in Webm is because Webm specifically doesn't allow non royalty free formats

its kind the whole purpose

let's leave mkv for pirates

<:PirateCat:992960743169347644>

and for obs recording

(unless you use fMP4)

> In mp4, recently you CAN encode both av1 and opus and vp9 inb4 frame timing mismatch cause source was mkv/webm, or not supported sub files, or missing color tables 😆

no thx

there is a problem that if there are no frames in .ts, if I encode it in MP4, and then encode it in MKV. There are no problems. But if I take ts -> mp4 and ts-> mkv And then take video from mp4 and sound from mkv, then there will be a collapse of synchronization. Therefore, I do not advise doing all this. I always convert ts to mp4 precisely because of the very important and serious standardization. I am absolutely sure that the broken ts file will be ideally located in mp4 and then you can do whatever you want with it.

the problem with block mkv is precisely in its ideology - it is blocks. While mp4 is monolithic, requires precision, requires seriousness, you need to understand this

yes

the problem for the regular user is mp4 can go into mkv just fine with dang near anything the mp4 contains, the same is not true the other way around

after all, that's the whole point of mp4 one video track one audio track minimalism. Embed it anywhere and it will work just fine. But mkv... uuh.

i suppose but everything that mp4 does so can mkv, it's waaay easier to edit, nowadays can be embedded dang near anywhere, i just dont see the point in dealing with the pain of considering what can and cannot be done with mp4

And here I also use mp4

I can compute SSIMU2 faster on my desktop than PSNR ahahah

(because the video reading interface is more efficient in the ssimu2 tool than in the PSNR one)

I recently did tests with SSIMU2 and there are indeed advantages. But as I understand it, AV1 is simply not designed for this, because I observed many other artifacts and blockiness that are not present on psnr. So all this should be done initially. In the meantime, all codecs are done with psnr priority

tune butteraugli was always broken, tune ssim usually performs better

Not broken Just too slow

it is practically broken, doesn't perform like it should

also doesn't even affect quantization...

but how can it broken if it works. I gave a video with the test

This

It doesn't perform nearly as good as it should

way too blurry

The latest release note of Discord iOS app says the full support of AVIF

if only it suppored JXL 😦

I have not seen any actual examples of things that are simpler or different at all in webm vs mkv

It's just mkv with a dumber sounding name

webm is very limited, you just can't put any codec there, you can't make 2 tracks, you can't have subtitles, webm is simplified very much to become a replacement for mp4 on the Internet

So it's just a standard mkv file then. It's not a separate format. Nowhere in the mkv spec does it say that every single possible combination of features and codecs is mandatory for mkv certification

I think that this question is what distinguishes the ideology of mp4 from mkv: No one cares

But mkv is defined and it does try to define every corner case... but it doesn't say that support for every possible feature is mandatory, it's just there and defined in case you were wondering how to support it. It's a free and convenient standard.

So if you wanted to add support for multiple tracks, it's defined, so you can choose whether to support it or not

It's very nice and very convenient and much nicer than mp4, which is developed by a committee of people who don't know what a file format is.

and yet, WebM exists

webm is not needed anywhere except in the web browsers

you can have subtitles (WebVTT)

<:Thonk:805904896879493180> ok

Idk why it exists honestly. And it's debatable if it even exists. That's like saying I'm going to invent a new image format called "webi" that's just a normal jpeg file but without support for progressive.

You could argue that I didn't invent anything. I just took something that already existed and slapped a different name and branding on something that already exists and has a name

BASEDLINE JPEG <:Poggers:805392625934663710>

Yes, based line

There was some reason why webp is not just one vp8 frame but a full new format. Probably Google wanted to have something 100% their own in webm

because AVIF is just one AV1 frame in heif format which was renamed to avif and nothing more.

i think if Google made webp2 based on vp9 it would be much much better. 10 bit+yuv444 and gifs compressed in vp9. Considering the simplicity of decoding in 2025, it would be perfect. Better than webp and more cost effective than avif now <:SadCheems:890866831047417898>

2% better than mp4 just cause cutdown mkv 🤣

Anyone ever heard of this codec before? https://lesia.jp/ I noticed Clip Studio is sort of using them, especially in their online manga reader offering, a demo of which is here https://www2.celsys.co.jp/bs/bsr4b/redirect.php?type=14 (decoder is in WASM) I'm kind of doubting their claims about being such a better image format, especially given the difficulty in comparing this to other formats

This page is not loading.

Ok. it's loading very slowly.

I might trying reverse-engineering their format a bit later, here's an example file

seems to be h264-based image+animation format with proprietary encoder+decoder - worse webp

criware, bink and spines/live2d in general gained overwhelming acceptance in the markets it seems to target (html5-type interactive games)

although h264 i-frame can be used as images, because no one prevents you from putting 1 frame in Mp4 and hide player line. It is better than jpeg but not better than webp. Still webp has more significant "tools" for compression, although h264 has macroblock division, it does not help much

too old

Anyone can use vp9 i-frame via webm but still no one does it.

what

how

<video> tag with hidden controls and webm file with just 1 frame I guess

<:KekDog:805390049033191445>

What bitrate is needed for ringli to achieve "transparency" under worst case scenarios?

And why is there no information about ringli besides the archived github?

?

https://github.com/google/ringli

very interesting does it aim to be competitive with Opus?

And what's with the li suffix? jpegli, ringli

Hmm, it also builds a metric

3kb AVIF screenshot moment 😁

Yeah WebP was mentioned at today's manga class

the "annoying" format

the software is not new enough that the teacher had to teach students the workaround by copying the image from a browser directly

and nobody knew what the f*** that P means

Zimtohrli

Web pee

Yes. According to Jyrki it kicks the ass of Opus

Universal / No-license / open-source?

Apache license

with license, I meant royalties, sorry

if that's the case, why hasnt google shown it off? especially under the aom label (even though opus is already royalty free and open source)

Opus proved itself to be reliable across the whole bitrate range

for movies, audio, speech, realtime

streaming music, etc

ive heard some mention it on the av1 community server and i *think* i only heard how its better than opus for low bitrate audio

so I am hesitant

what about high-bitrate scenarios

Obscure research project Jyrki is involved in. None of the researchers are that interested in or good at promotions and press releases.

I'll check

Presumably from Google Research Zurich which also created PIK/JXL

and I'll use their metric

Unless you like harpsichord music I guess

Opus still sucks at harpsichord

from \@afed guess i misremembered

I'll try

compiled it

I am not sure how reliable their metric is though. Let's compare some mp3, aac and opus first

https://discord.com/channels/794206087879852103/794206087879852106/1389501666004570204

wait what?

around 350kb/s opus is transparent for me for 7.1 audio

the claim is extremely bold

it's the file sizes, not kb/s

https://discord.com/channels/794206087879852103/794206087879852106/1390959027600625716

hmm, then it's very subjective

Samsung has a study on movie audio and 64/128kb/s is found to be transparent for mono/stereo

and around 40 for subsequent channels

I have never seen a 512k opus file

also about latency https://discord.com/channels/794206087879852103/794206170445119489/1375380854750314587

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

depends on samples and people/hardware, there are some samples where many people can hear the difference like on hydrogenaudio, there are many similar killer-samples and about 64/128 kbps, it's like the same studies when 128 kbps mp3 was transparent and equal to CD quality

haven't seen a study stating 128 mp3 to be transparent

320kb/s for stereo mp3 is known to be high-quality enough to be used in streaming

then streaming platforms started to use 128kb/s opus instead

some offer higher bitrates for premium users such as 192

If the difference is noticeable during multiple blind listening tests, it is not subjective except that not everyone is able to hear the difference or has high-quality audio hardware

and Zimtohrli https://github.com/google/zimtohrli/blob/main/CORRELATION.md

Hmm, this looks very promising

and it's very good with subjective scores it seems

yeah, and also these metrics and datasets are mostly for lower qualities (like VoIP), while Zimtohrli is more for higher qualities, so if there were only high qualities, the correlation would probably be even higher

isn’t it picture/pic?

Yeah but English isn't an official language here

https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases/v3.1.0 SVT-AV1 3.1 HAS RELEASED!

Why you think lossy WebP is better than one-frame H264?

<:PepeGlasses:878298516965982308> I saw.

I admit that AVC h264 can be theoretically better than cwebp at the moment. Because there are 4 technologies that can affect this, the original macroblock size is 16 by 16 pixels, the ability to split a block inside blocks, in the form of a hierarchical structure, while webp has either 16x16 or 4x4, the ability to fine-tune the deblocking filter, in theory a complete enumeration of all values ​​can give a better result (like webp -af), and of course the use of alternative modern metrics, maybe even Butteraugli. But no one made an encoder for encoding AVC frames as images, it is only a video codec, I can only say that x264 does not implement the theoretically possible advantages, because there is no point in it, because it is a video, not a picture. So at this particular moment, h264 frame is JUST NOT better than webp, you just can not create better, no matter how much time you have, no one is working on it --- and who needs to work on this patent crap.

☝️ short

this is the most unknown project in the world, I don't think anyone knows about it except 5 people on this whole discord server

It can't even be built currently

cmake dependencies conflict with each other so you need to comment some lines on cmakelists.txt

then it misses a source line

<:Stonks:806137886726553651> use vorbis if the audio is higher than 160 kbps then opus has no practical meaning You want quality, right? Youtube also still has a legacy aac audio track

then you can build it

open source project no builds linux only tutorial this guy dead since 0 seconds

And here is its obscure help page 😁

I see from the project like that the developers don't want their work to be used, so you can just skip it and forget about it forever Like Codec2

actually it's just in the research mode currently

there is no container that accepts ringli right now AFAIK

even the tool does not produce intermediate files. it directly outputs a decoded wav file

so it has no practical "use" currentl

you know, code, no articles, no one knows about it, no tests, nothing, someone didn't finish their sandwich and yucked it. Student interns' work

JPEG XL was in a private repo for years :P

You don't see a chef cutting carrots and then say no one will eat the meal because it's not finished yet

I think that this is not the main problem of Jpeg Xl <:SadCheems:890866831047417898>

Yeah, it's a little bit early to judge 😁

But it's also extremely early for bold claims

There needs to be a balance

the build issues are supposed to only affect developpers integrating ringli (and libjxl) in *source code form*. in practice, the overwhelming majority of integrations would redistribute prepackaged dlls (with whom build issues will never be an issue for downstream projects and endusers)

Open source does not work like that

I understand the project is not ready and not even announced

but your reasoning here is problematic

I would have rather kept the repo private

perhaps not for ringli but lgpl, mit and bsd always did so and we had 2 decades of projects redistributing non-gpl libraries like this

Hmm, what's easier is to compile this code on Linux or ask the neural network to write its full interpretation in Python to run it on my computer hmmmm

<:Thonk:805904896879493180>

Not so hard to compile on Linux

but there is no use if you are not doing a research

I agree, no builds are a pain, but when a project is so early like this they shouldn't be expected

I see a lack of understanding of the essence of the problem -- Why is the program not compiled yet?

Hmm, you mean a release

because it's a research project 😁

not ready

I guess the only problem is that people announcing it

and come up with bold claims

Apparently the developers wrote it without compiling a single binary file

No, this codec currently does not achieve 60% efficiency compared to Opus

It will stay that way until we see a compressed file that can be decoded directly within a player and that offers the same quality but is 60% smaller.

There is probably more updates on this codebase but I assume they currently don't share.

So basically it boils down to, "I'll believe it when I hear it"

I especially like that the open source community turns a blind eye to this. No one has ever been able to answer the question -- if you wrote the code, you built the program for yourself to run it, why didn't you post what you built? just pack this shit zip and drop, they don't take money for it

developers generally (almost always) use Linux, and there are times that builds are not ready to be distributed

the codebase changes very quickly

and the binaries are useless

If the build was can not ready, why is the code posted?

That, I agree

but it's archived anyways

It's not different than a repo from a random person's github; in its current form

I understand that there is such a thing as rolling-based like arch where binaries are basically meaningless because you can always just press a button and build everything. But that's definitely not my way. I want to have a file that I can run today and in a year and it will just work

it is not something impossible to achieve and it is stated for high quality, though with any more modern researches in compression it is pretty much possible and opus is based mostly on very old and not the most efficient algorithms and at the beginning was inferior even to mp3 in many cases, but over time the encoder has become better tuned

And yet, there are build instructions, but no binary. Well, that's it.

possibility is not important here

currently it's not even on par or not even worse

You said it in a complicated way. Say it more clearly -- the current opus algorithm is an improved Speex codec algorithm

That would be a simplification

and yet. they've just been doing it for 20 years

possibilities and current use are often conflated far too often

Exactly

celt, not speex celt + silk

VVC also showed many possibilities years ago

~~just use rust so we can install with `cargo install`~~

it's currently useless. can be considered non-existent

at least you can embed it in an mkv file and a recent-enough mpv/ffmpeg can decode it

we need more cool stuffs [cheems](https://cdn.discordapp.com/emojis/720670067091570719.webp?size=48&name=cheems)

slightly not wrong, because I watched the interview of the developers, since they created both codecs from Xiph, where they specifically said that opus, which is celp, is like a new speex at its core

silk just skype just dead <:KekDog:805390049033191445>

although for those who like to compress hard, it's still life

well in general yes. i found only one use for it, vvc better than av1 compresses at extremely low bitrates, for example 8 hours of cyberpunk gameplay in 2 gigabytes, looks fun. no other scenario for using VVC was found, it sucks

interesting usecase

ffmpeg.exe -i D:\kb\25.mp4 -c:a libopus -b:a 96k -apply_phase_inv 0 -frame_duration 60 -vbr on -c:v libvvenc -qp 38 -preset medium "VVC-kb-25.mkv"

yes i uploaded the video to youtube but i wanted to keep a copy so i wouldn't have to store 200 gigabytes of originals

I'll say this about vvc: if set the preset faster, it loses to AV1, if make the quality better, it loses to AV1, there is zero support, no hardware. In general, well, screw it

Opus is an improved CELT for high bitrates and SILK (from Skype) for very low bitrates, merged into one format CELT is different and developed separately, originally something like low-latency Vorbis there are some similar ideas with Speex, but overall they are different

> like low-latency Vorbis no

I have been using and studying opus for 7 years, where is this information from, I know the band frequency level that is used for the stereo channel at each given bitrate

Opus has CELT, SILK and hybrid mode.

SILK for lower-bitrate, speech-optimized audio (developed by Skype).

CELT was developed by Xiph.Org (the Vorbis people) and shared some design philosophies with Vorbis, but it is fundamentally different: Transform-based, tuned for ultra-low delay (<10ms), and not a descendant of Vorbis.

WAV original OPUS 256 VORBIS 320 opus has more problems precisely from linear prediction. more than jpeg xl from xyb. Because in the end it sounds better, by ear

Speex was a completely different, older codec based on CELP, primarily used for VoIP. Opus replaces Speex but does not inherit its codebase or algorithms.

first picture signal difference, opus gives the biggest artifact, more than mp3

Opus is not based on Speex. Speex was deprecated by its own author Jean-Marc Valin, who then co-developed Opus. While both are for low-bitrate audio, Speex used CELP; Opus uses SILK + CELT, and the technology is completely redesigned.

the second picture is what the wave really looks like, opus is the most crooked, opus doesn't care

SILK is closer to a CELP-type model, but Opus isn't just an "improved CELP". It switches to frequency-domain coding at higher bitrates and for music.

the third picture shows the amount of artifacts, at high frequencies, opus is terrible

fourth picture, aac-he removes frequencies, opus fills them with noise, looks beautiful, sounds terrible, aac-he at 16-32 kbps sounds better for music

the linear prediction algorithm works very simply, OPUS delete frequencies, and then recreate, here is a picture from some article of development, where the signal is shown before linear prediction, when the opus codec deleted it, and the final signal that it recreated. It works like as CfL AV1

in fact slik is never used alone, never. It is always used only for voice, which is determined by the codec, and it is also used only for low frequencies, usually 8000 hz and everything high is encoded block CELP

the fact that there are giant blocks is the reason for large artifacts at high frequencies, in this case, almost like blocks for DCT, for the same reason there is always so much noise at high frequencies, and even more problematic is that the block boundary is not 16000 but 15500, which is why even with a cut of 16000 the entire block from 15500 to 20000 will be noisy Welcome to OPUS

NEVER GOOGLED

literally in the opus documentation it is written about it, literally they have one developer, I don't see any reason not to say that celt is celp 2

I only admit that in my head celt and celp are the same thing, because same linear prediction, because xiph, because one developer, because one difference in the letter

[CELT] Valin, JM., Terriberry, T., Maxwell, G., and C. Montgomery, "Constrained-Energy Lapped Transform (CELT) Codec", Work in Progress, July 2010. Code-Excited Linear Prediction, or CELP

oh, that good old Montgomery. Just yesterday I translated his video into russian using a set of neural networks = whisper + gemini + silero tts

it's funny that celt is originally a speech codec, and opus contains 2 speech codecs, one is more speech than the other haha. But as I said before, the way from speex celp to celt to opus 2025, these are different codecs, even opus 2013 and opus now. But its all connected by common technologies and ideas of the same developers for all of them, I literally still remember how in 2017 opus sounded much worse than now, at bitrates like 64 kbps, it still sounds disgusting in mono if you listen to it from 1 speaker, so you need to write -apply_phase_inv 0 but no one even knows about this, stereo artifacts occur at a specified bitrate below 120

There is a sadder thing, that 5 years ago, that now - there is not a single codec that claims to be better, to replace opus. There was one, some kind of usuck, unfortunately no one looks at it seriously, I wonder why

MP3 320 -q 0 FOREVER 🤙

We live in amazing times when a large program of 400 lines of code that makes a super-precise block display of the full structure of OPUS file is done by CTRL-C CTRL-V from documentation to a neural network and waiting 2 minutes

Demonstration of libopus (-b:a 16k) -frame_duration 60 which I always use, as it pack 3 blocks into 1, reducing the amount of service data, which for a couple of hours of video flows into a couple of hundred useless kilobytes. But if this is a very strong compression of the sound, then the effect from them will be proportional

in automatic mode there has been a bug for a long time that slik is used at the beginning of the file, which spoils such files as, for example, compressed sounds in a bitrate of less than 64 kbps (when slik is used) for files of sizes such as 1 second (sound effect)

is that a normal way to downscale an image? https://x.com/zimonitrome/status/1949597574551216226

no, that is horrible way to downscale a palette image. Either you treat it as full color and then keep it full color (or if you like, requantize it to palette but independently from the original palette!), or you try to preserve the original palette but then you can only use NN downscaling.

or maybe at least a distance that gives much more weight to hue and saturation (but the end result will probably end up looking like NN anyway)

[sorry for the spam] Just wanted to say that theguardian.com is on `tune=iq` for the last two weeks (we serve AVIF to non-JXL-supporting browsers) and we couldn’t be more happy. Encoder consistency is much, much higher (still not as good as JXL, but that’s just an impression, not a rigorous assessment): some highly compressible images where delicate detail was being obliterated grown even ~3× in filesize and look much better while unnecessarily weighty images shrank, mostly without any perceptible degradation. Interestingly, we kept the same quality values (which differ by dpr) and as much as we can say, the overall bandwidth stayed more or less the same (I can’t see any change in the graph), so it’s likely the massive reduction of rare weighty images offset small images growing. Huge thanks to <@297955493698076672> for his work on `tune=iq` and to whomever else worked on it. And to friends at our image CDN (Fastly). And to everyone here as without this server, I wouldn’t even know about it… As always, we welcome improvements to any and all encoders. So the idea of [splitting Julio](https://discord.com/channels/794206087879852103/805176455658733570/1376249806917210224) couldn’t sound more exciting 😉 .

just took JPEG pics shot by GCam simple `ect` got 700KB (20%) smaller file and `ect -strip` got 1.5MB smaller file 0.o So I guess there was quite a lot of data in EXIF/metadata what tool should I use to see all that ?

with `jhead` I can see that the there is a 20KB thumbnail, and quite a lot of "Map" objects even though I don't really know they are

https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2292

From **JesusGod-Pope666-Info**

⚠️ **You startled the ~~Witch~~ Evangelical**

**partition_limit** funny webp problem. header maximum vp8 must be up to 512kb in size. This means that despite the 16k x 16k limit for webp -- Technically it is very difficult to achieve, because much earlier problems will begin with the fact that there is not enough space to place information about the position and modes of blocks

moreover, even at sizes of 4000x4000 problems with this may begin

Dimension: 14350 x 14089 -q 44 -m 6 -segments 1 I had to lower the quality until it could create a file. -m 1 -m 4 -m 6 the same gave an error on the same quality, so you can do a quick search -q on -m 1 and when you get the encoded image, run with -m 6

the function -partition_limit 100 which should solve the problem does nothing, only -segments 1 helps

<:VP8:973222137202610226> <:This:805404376658739230> <:WebP:1279637593868210368>

4 months ago I found a lab paper about jpeg, which describes in the most detail its minimal possible implementation with encoding only the Y brightness channel at baseline. And today I got around to working on making the neural network write working code according to the document, and I did it, everything works, now I have jpeg at home <:bayer:1284515744981450824>

<:BlobYay:806132268186861619>

The original document about jpeg from 1992 is of course huge, but I think it is not a problem to make it completely

It's funny that the true original quality setting function is not Q 0-100 but literally -d 1.0 like in Jpeg XL, and decreasing the value increases the quality

in general, i would say that the most technically difficult thing in jpeg is this first LUMA quantization table, because it is literally the most difficult non-intuitive thing that cannot be simply generated. I did not find who exactly created it, but it seems that half of all the efforts in developing jpeg were in this table, because these are like the numbers of God without which it is impossible to create everything else. And they have not been updated or changed for more than 30 years. as if the numbers were initially absolute... Does guetzli jpeg do exactly that, it creates a new table based on the input image using butteraugli...

interestingly, a full implementation of DCT from scratch gives a more accurate result than scipy.fft, by 0.1% of blocks, due to rounding errors, which are no longer present

I remember I tried to find a pure python implementation of jpeg on GitHub several times. 5 years ago, and I think 2 years ago. But it doesn't exist. Well, now it will (but not on GitHub)

https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=225417

Davini Resolve now supports WebP lol

I wrote a complete implementation of the JPEG encoder yuv420 baseline **in pure python** without using external libraries ||(except decoding the input image)|| according to the ITU-T T.81 documentation https://www.w3.org/Graphics/JPEG/itu-t81.pdf from 1992

Does anyone know a codec designed for very high resolutions? Does it exist? Filesize doesn’t really matter (within reason), and ideally it should be lossless. Im asking this because a few years ago i made a python script create an image roughly 32k resolution but it was super slow and laggy to open and zoom in on.

Could jpegxl be used for this? Im a little scared because im not sure it will be “fast enough” to decode and what not

I believe it probably could in theory, but you’d want cropped decoding and so on

for an optimal experience, you would want tight integration between the viewer and the format

Idk if something exists kinda like google maps that gets progressively more detailed, the more you zoom in?

Also, what is a great image viewer for windows? Something modern yet very fast would be ideal. I don’t need it to do any simple editing. Just pure viewing.

use tile

Because if it’s anything like the windows media player then its awfully bad. I replaced that with mpv and its so much better

“Tile”? Is it a codec/format?

depending on the use case, maybe https://github.com/Tom94/tev could be suitable?

admittedly, I haven’t tried it on images that large, but it feels rather fast in general

Interesting. Ill try out this viewer

JPEG XL supports tiling through a concept called "groups," which are rectangular image tiles that can be decoded independently. This is a key feature for enabling parallel decoding, region-of-interest decoding, and handling large images efficiently. Here's a breakdown of how JPEG XL handles tiling: * **Groups**: The image data in a JPEG XL frame is divided into groups. These groups are analogous to tiles in other formats like JPEG 2000. * **Independent Decoding**: Each group is a self-contained section of the bitstream, allowing it to be decoded independently of other groups. This is what enables parallelism and decoding of specific image regions without processing the entire file. * **Table of Contents (TOC)**: The frame header includes a TOC that stores the bitstream offsets for the start of each group. This allows decoders to quickly locate and process specific groups. * **Group Sizing**: * In **VarDCT mode**, which is used for lossy compression, groups have a fixed size of 256x256 pixels. * In **Modular mode**, used for both lossless and lossy compression, the group size is more flexible and can be 128x128, 256x256, 512x512, or 1024x1024 pixels. * **Group Ordering**: By default, groups are ordered from top to bottom and left to right (scanline order). However, this order can be permuted, allowing for orderings like center-first, which can improve the perceived quality of progressive decoding. * **Clipping**: For groups at the right and bottom edges of an image, their dimensions are clipped to match the image's dimensions. https://arxiv.org/html/2506.05987v2

Its a need

> JPEG XL supports tiling through a concept called "groups," which are rectangular image tiles that can be decoded independently. Groups are squares...

JXLs can use progressive loading for something similar. If you're zoomed out, it can load a 1:512, 1:64 and 1:8 preview before then loading the full res groups for lossy. <#1065165415598272582> has cropped decoding support, albeit experimentally

I will need to learn how to do that

```--progressive_dc=-1..2 Number of progressive-DC frames, default = -1. -1 = encoder chooses. 0 = disable. 1 = extra 64x64 low-resolution pass. 2 = extra 512x512 and 64x64 passes.``` Issue is, no image viewer has taken advantage of it yet...

Rage

And libjxl only outputs the scaled versions (for 1:512 it would render as 32K instead of 63 pixels), though I have suggested changing that <https://github.com/libjxl/libjxl/issues/4297#issuecomment-2993248222>

With the changes me and Homosapien made, we got JXL decoding twice as fast as PNG with `--faster_decoding 4`

Usually they are. At the right and bottom edges of the image, they're usually not square.

I assumed they're square, but just cropped to the canvas size

yes — but a square that is cropped is no longer a square 🙂

also, squares are technically rectangles

even if the colloquial meaning of rectangle is “non-square rectangle”

Now I'm having flashbacks to WebP2's triangular pixels

hexagonal pixels have been proposed as well

https://ieeexplore.ieee.org/document/1013056

fascinating ... why would they do this?

hmm, I thought it was triangula*tion* for WebP2

lemme check

All I remember is something about triangles or polygons, it was years ago I saw it

https://arxiv.org/pdf/1809.02257

found the paper

feels like a code golf project made into a paper lol

it’s fun but a bit disgusting

basically a form of edge preservation for such low rates

It's weird that the "WMPhoto" encoder is still mentioned on PowerToys' resizing tool

it's because internally in Windows the JPEG XR encoder is still called that and the PowerToy devs don't know any of the history or anything else and just exposed that encoder like that

https://github.com/orgs/community/discussions/169478

Github now supports TIFF and BMP images

We are truly living in the future

I left a comment mentioning JXL support, since someone complained about WebP and AVIF

I'm trying to implement a xyb jpegli decoder, but somehow I don't get the correct results even before color conversion from xyb to rgb. I know that it uses 3 quantisation tables, one for each channel, and that the huffman tables are the same for X and B channels and Y has has its own. Is there any other difference to "normal" jpeg that I'm missing?

do you take into account that they’re RGB as opposed to Y′CbCr?

doesn't seem to have `cjpegli` in here ``` jxl_0.12.0~alpha20250815142758-0+git03e432d_amd64.deb jxl-dbgsym_0.12.0~alpha20250815142758-0+git03e432d_amd64.deb libjxl_0.12.0~alpha20250815142758-0+git03e432d_amd64.deb libjxl-dbgsym_0.12.0~alpha20250815142758-0+git03e432d_amd64.deb libjxl-dev_0.12.0~alpha20250815142758-0+git03e432d_amd64.deb libjxl-gdk-pixbuf_0.12.0~alpha20250815142758-0+git03e432d_amd64.deb libjxl-gdk-pixbuf-dbgsym_0.12.0~alpha20250815142758-0+git03e432d_amd64.deb libjxl-gimp-plugin_0.12.0~alpha20250815142758-0+git03e432d_amd64.deb libjxl-gimp-plugin-dbgsym_0.12.0~alpha20250815142758-0+git03e432d_amd64.deb ```

also I couldn't seem to find an older build of JXL CLI tools that included `cjpegli`

Maybe it's Windows only, looks like you don't have any of the debug tools

Hey <@121325908312195073>, I just saw your work on enabling ZSTD by default for Blender PointCaches <https://projects.blender.org/blender/blender/pulls/144356> Not sure if you were aware, but a while back I suggested doing the same for blend files, after we enabled it by default for autosaves. Don't suppose you'd be interested in doing the benchmarks? https://projects.blender.org/blender/blender/issues/135735

Your data filtering reminded me of this issue too, though there's no clean solution and it only occurs in specific scenarios https://projects.blender.org/blender/blender/issues/120901

VP9 in 2025 is like a good wine that just needed to age <:VP9:981490623452430376>

If you download videos from YouTube, download vp9 and not av1. quality of AV1 is worse than VP9, although AV1 weighs less, VP9 contains more of the original quality

AVC for video is finally dead

RIP F

<:SadOrange:806131742636507177>

difference are so small

YouTube's AV1 has gotten better recently, but for a long time it looked awful https://discord.com/channels/794206087879852103/805176455658733570/1379645351107235840

no more vp9 <:monkaMega:809252622900789269>

AV1 really got better but vp9 is still better for saving and working with "original" video

I'm aware

It still looks MUCH WORSE compared to VP9

- Fast HW encoding - Encoding from lossy source - Bitrate starved