JPEG XL

That's not the impression I got when I read the article. I'll double check though.

you can see whatever light went directly from the light source to your eyes, but you cannot see whatever light went in any other direction

Be aware I would not trust Wikipedia to be accurate on anything.

exactly, alpha 0 just means the light isn't being directed into the lens

that doesn't mean that the energy is gone

its just "not visible"

The impression I get is that emission is a multiple of occlusion and 0 is fully occluded

But I'll double check...

It's impossible for this to be true. If this is what the article leads on, then the article's just wrong. Wouldn't be the first time it's happened.

imagine the background is a solid piece of felt, pure black, alpha=1. Now imagine you have a transparent light emitter in front of it, like a candle. It has alpha=0, but RGB=1,1,1. What do you see? You see 1,1,1, despite the candle being alpha=0 and the background being 0,0,0.

Adobe used a few misinformation about Associate Alpha all the time because they refused to fix their shit and their goal was to convince everyone that they were right and everyone else was wrong.

If I'm right then it should not be possible to have an alpha of 0 and a nonzero emissive value at the same time since that's division by zero

correct

https://community.adobe.com/t5/photoshop-ecosystem-discussions/change-in-exr-open-from-cs2-to-cs3-can-this-be-fixed/m-p/1521042/page/4#M918

but that's proof as to why you are wrong, because it is possible (unlike unaccositated alpha)

Or maybe it's too expensive for computers to double check that values make sense before doing matrix multiplication?

it's not expensive at all

well maybe in the 90s

but they do make sense

the VFX industry is all in on associated alpha for a reason, it allows for something that unassociated alpha simply doesn't

In your model, you would first subtract the alpha and then add

Your additive model doesn't make sense to me. In theory you can just keep adding but I don't think anyone does that in practice... In practice they're added and then divided as if averaging.

Also, the article says at the beginning that the term alpha comes from "linear interpolation formula" which is not adding

Linear interpolation has a very clear meaning and it's not adding like you're describing

It's averaging

just because a term comes from something doesn't mean that that thing is the end all be all of everything afterwards

Well, if it's called alpha...

like, just look at the text

that's the formula

it ain't my model

You can see why I thought of it the way I did and got this impression

For some reason the formulas do not show up in safari...

rip

that's annoying!

> Premultiplied alpha may also be used to allow regions of regular alpha blending (e.g. smoke) and regions with additive blending mode (e.g. flame and glitter effects) to be encoded within the same image.[7][8] This is represented by an RGBA triplet that express emission with no occlusion, such as (0.4, 0.3, 0.2, 0.0).

This equation looks perfectly compatible with additive blending

yeah. That's sorta the point. See the text I quoted right above. When the foreground is alpha=0, foreground and background are simply added together.

I wonder how it works for jpegxl. It's a floating point format so loss of precision isn't a problem...

JXL supports both

Btw why does it make sense to say associated alpha when the brightness of a pixel is NOT associated with the alpha?

It makes more sense if it's associated because it's premultiplied

But if that's incorrect then in what other sense is it associated

So the file says what pixel format the values are using in other words?

So it's always unambiguous?

I believe so yes

yeah there's a flag that says whether the alpha channel is associated or not

Cool. But what is it "associated" with exactly if they aren't premultiplied?

ask whoever invented that name

and when you do blending inside JXL with multiple frames or patches, you can tell it which blending algo to use, I think.

Hmm. All these things conspired to make me initially believe that premultiplication is a logical term to use

Yes and surely this is specified as a very simple algo that doesn't require converting the colorspace to a linear one

keep in mind that you can do all the math to make it work out right in the end during encoding, since you know exactly how the decoder works

Yeah, there shouldn't be a need for anything so advanced as being able to convert arbitrary colorspace to linear

the attitude of Chris in that Adobe thread is frankly appalling

it really was quite something, the thread itself is very enlightening though, btw this thread is pretty notorious now

hg2dc has a good explanation here https://hg2dc.com/2020/08/26/question-25/ > It would be challenging to dream up a worse term for such an encoding. Put something math-nerd in a term and you can be guaranteed that math nerds will get obsessed with the math nerdism of the subject, and completely forget the idea that RGB values are emission intensities. Mr. Gritz, cited below, was one of few sane people who chose to use the TIFF specification terminology associated alpha. As with All Things Gritz, it is a decision rooted in wisdom.

the tiff spec did right by calling it associated alpha, but sadly goes on to define it as below. so kinda one step forwards half step back > associated alpha specifies that color components are pre-multiplied by the alpha component

I posted this one before, but it actually does a good job. "premultiplied" does *sometimes* make sense, it makes sense when you do the process of converting unassociated alpha to associated alpha https://groups.google.com/g/osl-dev/c/3QKlnfW6dB0/m/KdziBfxeBgAJ,he > the PNG file format specification dictates that color should not be premultiplied (also known as "unassociated alpha"), and the OpenEXR specification is pretty clear that color should always be premultipled (also known as "associated alpha"). > ... > By default, OIIO's texture system will automatically premultiply upon input, for image files that appear to be unassociated > ... > There is an option ... that will turn off this behavior, i.e., to leave unpremultiplied colors as they were in the file. If you do that, then, the shader itself needs to do the premultiplication to use it as ordinary texture > ... > > So the way that OpenImageIO ... deals with this is to attempt to determine ... its best guess on whether an image being read is associated or unassociated alpha, and for the latter will automatically premultiply in order to present the pixels on the app side of the API as if they were premultiplied.

In jxl we support everything: premultiplied or not, but also funky stuff like negative alpha or alpha > 1 which can perhaps also have interesting uses

I computed a new Instagram aac encoder

When new array of commit or announcement?

perhaps unassociated alpha could be renamed to “normalised alpha” or something like that

(it assumes that emission won’t be more than occlusion and therefore rescales 0-1 to represent 0-alpha)

maybe “normalis**ing** alpha” to make it clearer that alpha is the normaliser and not the normalisee

That's for formula 1 videos will help

Fixing moire in jpeg xl and avif those new fast speeds

What do these constant out of context screenshots mean

i hope in a week we will have some builds

I don't think questioning Fabian's logics will really bring you anywhere <:KekDog:884736660376535040>

pashifox found 5 new bugs on the encoder side

isa good news gweewhwef.txt

Names aside, what makes more sense depends a lot on the use case imo. When editing images like composing two photos with a smooth "crossfade" between the two, it makes sense to see alpha as a selection mask that is independent of RGB (so unassociated/non-premultiplied). When modeling a scene using semitransparent layers where you want to have both blending and additive (emissive), associated/premultiplied is needed because otherwise you cannot have emissive light. Though if you allow sample values outside the [0,1] interval (both for color and for alpha), you can also model things that cannot be represented when everything has to be in that nominal interval.

It needs a tablet to do properly but now i did some new results

Tedious

I think look more like vp9 than jxl but why wb,;

What i did wrong today on hall website

I found this gem of a comment on YouTube....

Aomedia is too slow 13 secondd a single image isn't ready

Jxl has already encoded

so yet more misunderstanding of associated alpha?

is it that recent video by the half-silver-face guy?

(I don’t remember his name right now)

Captain Disillusion, yeah. That's the top voted comment under that video

The video isn't great, but it does mention that associated alpha allows for some things that simply aren't possible with unassociated alpha, and isn't just an optimization. So it's funny that Crocker ignores that in his comment. Maybe he just didn't watch it.

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

I’m going to reply with this

🙏

incidentally, is there a standard way of doing 3-channel alpha in JXL?

Presumably it's perfectly possible since you can do whatever you want with any number of extra channels, but with JXL support probably coming to VFX tools like Blender in the nearish future, I wonder if there will be an agreed upon convention for this case.

honestly on my r580 avif looks identical to jxl

butcan't make jxl identical to avif

That has nothing to do with the question you're replying to...

also, being identical should be symmetrical

watch creators of a format ruin a format and decades worth of beginner VFX artists exports with one funny line

https://www.smbc-comics.com/?id=2475 ```python .append("the only benefit of premultiplication is faster compositing") ```

xD

Lol

it's not even like it was unknown the benefits at the time of PNGs inception. Porter and Duff's excellent paper came out in like '85. OFC it's entirely possible that they were unaware of it. But I feel like they information would have been available for them.

Like they **knew** about pre-mulitiplied which according to alvy ray's "Alpha and the history of digital compositing" actually was first provided as terms and technologies by that specific paper

oh sorry the original paper was '84 https://graphics.pixar.com/library/Compositing/paper.pdf

Is that a thing? So R,G,B each get their own alpha value?

You can have 3 alpha channels in jxl, but frame blending is defined in the spec to use the same alpha channel for blending R,G and B.

yes, EXR supports that: https://openexr.com/en/latest/TechnicalIntroduction.html#deep-data-special-purpose-channels-and-reserved-channel-names

(with the following note: “If a part contains RA, GA and/or BA channels, it must not also contain an A channel.”)

For a single layer image, we could easily just have a convention that if there are 3 alpha channels, they correspond respectively to RA, GA and BA. For multi-layer, we currently don't have any way in the spec to do alpha blending (of frames or patches) with 3 alpha channels instead of 1. Should we add an extension for that?

it sounds niche, but its actually pretty important, say you are rendering/simulating a lens that filters out red light. you could do (RA GA BA) (0,100 100,0 100,0) or something like that, I think I got that right. its uber late

well its more like 0,90 or something

We also have other blend modes in jxl, e.g. you could have a kMul layer with color (0.9 0 0)...

that seems like a pretty sensible way of doing it

So you'd have a background layer, a kMul RGB layer, and then a kAdd RGB layer.

Yes, there is https://github.com/wwww-wwww/spline and the article: https://grass.moe/splines/

I've made an SVG2JXL test some time ago: https://discord.com/channels/794206087879852103/824000991891554375/968503089663442944

it doesn't translate perfectly though, at least currently

it will never translate perfectly

jxl splines are too weak

Weak? Is it a mathematical term?

I wouldn't say they are weak, jxl splines can do things you cannot do in SVG, but you can also do things in SVG that cannot be done with jxl splines. In particular jxl has no notion of filled shapes.

You can approximate filled shapes by drawing thick splines from the center of a shape to its edge, but it's not very accurate. Also JXL splines aren't as sharp as SVG paths. But they are really compact in terms of file size for complicated paths.

Yuv420 is less pixels so obviously it's faster to decode, but you're blurring the color channels

Harpsichord music last I checked sounds like ass with opiss

And yeah jxl is a raster format, splines are not meant for vector graphics, they're meant for being subtracted from an image during preprocessing phase to improve the efficiency of DCT

Just stick to brotli compressed SVG

It's perfectly fine to have .svg.br

There's no law against it

blurring is a decoding problem. It's not inside the image.

I writed my own RGB to YUV420 for this, in pure python

Yeah, it is inside the image. If you convert to 420, you are throwing away a whole bunch of pixels, shrinking the image, which is essentially blurring it.

Smaller images are faster to encode and decode of course but it's severely destroying the fidelity of the image

Lossless cjxl at effort=1 is ludicrous speed. And smaller than PNG. Try that

No need to mangle the image when you could just use a faster encoder. :)

Also when you use low effort settings it decodes faster too.

Effort=3 or less is very very fast

Normal (associated)

well, we know where the authors of PTGui stand

lol

Hi are there any other discord servers that discuss image/video compression? I really had a hard time finding anything

https://discord.gg/AfhGNDpM

https://discord.gg/ZvtV6wya

https://discord.gg/HhCtDUDbgm

https://discord.gg/hSrjUCMncC

https://discord.gg/P2ZQSuGbkF

Thank you both so much

TIL that ImageMagick `convert input.png -quality N output.jp2` does not do what I assumed it would do

in particular, `N`is not on a scale from 0 to 100 similar to that of its jpeg or webp encoding

but it is expressed as a target PSNR score

i.e. if you give it any value above 50, it's extremely high quality

Oh i ran into that problem a few months ago but i didnt look into it to see why the scale was so different

this behavior is pretty unintuitive and has caused me some head scratching before I figured out what was going on with that scale

Yeah it is very unintuitive, im not terribly familiar with j2k but does its quantizer not map to 0-100 trivially? I cant think of a reason why they would make it like this otherwise

ImageMagick is funny in that way, its `-quality` parameter can mean quite weird things (e.g. when encoding PNG, you can configure some libpng effort settings using that option)

Im curious how they target PSNR

No image format maps to a 0-100 scale trivially, you always need to do some kind of translation from a user-facing quality scale to internal encoding parameters. And you can never perfectly align scales between different encoders/codecs, you can align them according to a metric but even then you'll only get corpus-level alignment, not image-level alignment (and no metric correlates perfectly with actual image quality).

But why choose a wildly different parameter to begin with

Like you said given the HVS, PSNR essentially caps at ~50

For visually lossless

And anything under 30 or 25 is very undesirable

Weird to pick that as the quality parameter

I'm only in that as is video focused and not media, Android and seasonal. And the admin is serious intelligent. The best information Ive found is that on jxl Discord "

Targetting PSNR is not that hard, since PSNR is such a simplistic metric. Essentially PSNR is just directly related to quantization (coarser quantization -> lower PSNR).

True, a lookup table could be used to map it

the error introduced by quantizing pixel samples in 8-bit corresponds to PSNR 54

I had some per code block or coefficient control loop in my head for some reason

Oh interesting I didnt know that

PSNR is defined as 10 * log_10(1 / MSE), if the mean square error is computed with sample values on a 0..1 scale

8-bit quantization introduces a quantization error of 0.5/255 on average, so that's PSNR 54

or wait, the quantization error is I guess only 0.25/255 on average (it's 0.5 in the worst case, if you round to the nearest 8-bit integer)

So for j2k you'd need to know how much the quantization of each subband will effect the PSNR of a decoded pixel?

Or am I really overthinking this

PSNR 54 is the quantization error of using 8-bit samples, it's 10 * log_10(255 * 255 / 0.25)

yes, something like that, but iirc in j2k the encoder can just truncate the coefficients at exactly the spot it wants to achieve a given bitrate or PSNR, so it can easily achieve almost exact bitrate or PSNR targets

(unfortunately, for human-consumed lossy image compression, you don't really care about bitrate nor PSNR but you care about perceptual quality)

Ohhh right it has that progressive aspect

Yeah... I'm relatively new to this field (about 2.5 years so far) as a hobbyist so I've been slowly learning and realizing these things. The lack of one all encompassing good metric to capture perceived quality seems a huge obstacle for more effective codec development

Progress has been made with Butteraugli and SSIMULACRA 2, but it's still not a solved problem

I took the initiative a while back to revive the JPEG AIC adhoc group (Assessment of Image Coding), I hope AIC-3 will help to get better subjective ground truth datasets (https://jpeg.org/aic/aic3.html) and then AIC-4 will hopefully result in better metrics

Oh yeah I've heard of Butteraugli, haven't heard of SSIMULACRA 2 but I am familiar with SSIM

Sweet, how long have you been in this field?

SSIMULACRA 2: https://github.com/cloudinary/ssimulacra2

I started playing with image compression when I started what would become FLIF in 2010 or so; professionally I'm in the field since 2016

I go to JPEG meetings since 2018

Oh no way! That's awesome, nice to meet you

Have you gotten into video compression or is image compression your preferred field?

I only do image compression, though of course I sometimes do discuss video stuff with my colleagues who do video

👌 Fantastic

I rebalanced the presets hope it wouldn't be damaging to the codec

The thing is that doing those things is a bad way to speed up jxl interframe patches

And copied and probably you could have a patent strike

@jpeggers is min_DCT_h_scaled_size always smaller than min_DCT_v_scaled_size?

<https://github.com/libjpeg-turbo/libjpeg-turbo/blob/main/jpegapicomp.h#L17> make it looks like it is but intuitively I can't tell

likewise, what even is scaled DCT in jpeg

can someone tell me what the fuck is written here if *-pass 1* in ffmpeg creates an empty .log file. And *-svtav1-params pass=1* does not create any file anywhere at all

Maybe I'm stupid and don't understand simple things. ~~but pass 2 for svt-av1 is not implemented for ffmpeg. It just doesn't work.~~ in fact, I remember doing this a year ago, or 2 years ago, the neurons in my brain remember that it workS, I'm trying to remember why

I definitely remember that this is some kind of stupid bug. Just facing the fact that IT doesn't work ```./ffmpeg -i IN.mkv -c:a libopus -c:v libsvtav1 -b:v 650k -pass 1 -preset 12 OUT.mkv```

and IT doesn't work ```./ffmpeg -i IN.mkv -c:a libopus -c:v libsvtav1 -b:v 650k -preset 12 -svtav1-params pass=1 OUT.mkv```

I remembered a bug related to AOM - if you create a video with an audio track when creating pass 1, the pass.log file becomes empty. But this is about libaom-av1 - it has nothing to do with svt-av1, it doesn't work that way. parameters -svtav1-params pass=1 does start the Pass 1 creation mode --- BUT it does not create a file, Nothing. At the same time, according to the manual https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Parameters.md#multi-pass-options I can set the output file ||no||

great (but there was no answer there either)

yeah, not all encoders work with multi-passes through ffmpeg, so needs piping at least also 2-pass for svt-av1 is pretty bad, all modes except crf have much worse efficiency

It seems that I writed this

The problem is. That the developers' github says that it works "we did it." But it doesn't work. (at startup, it writes that it has switched to a special mode. it is FAST (2 times faster than preset 12)) BUT nowhere is there out or anything at all

for example, something like this for windows should work ```ffmpeg -i xx -an -f yuv4mpegpipe -strict -1 - | SvtAv1EncApp --rc 1 --pass 1 --preset x --tbr xxx -b NUL -i stdin ffmpeg -i xx -an -f yuv4mpegpipe -strict -1 - | SvtAv1EncApp --rc 1 --pass 2 --preset x --tbr xxx -b "xx.ivf" -i stdin```

1. I have linux 2. for what reason should I use an external svt and not the one in ffmpeg. You solve the task but you don't solve the problem

for linux it's something similar, just `null` and maybe some other changes because svt-av1 devs don't really care about ffmpeg except for single pass modes and basic options

It doesn't matter. this does not solve the problem.... I'll have to create a thread on 4ch, oh, how I didn't want to go there.

if i am not confused i used to do 3-passes purely through ffmpeg for 2-passes I only used piping (after it was changed), it works, but again 2-passes for svt-av1 are bad (half of the settings and tunes doesn't work), it exists but much less efficient, the other rc modes are just there on paper but basically useless, have a lot of issues and it won't be fixed anytime soon if at all 2-pass is only useful for 2-pass crf btw, about the other topic, vb has been finally merged recently <:Hypers:808826266060193874> https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2195

Don't say that. because it makes av1 unusable for me at all

I encode with a size limit that cannot be exceeded. if pass 2 cannot give me a CRF according to the pre-calculated video data, this means that I will need to do 2-3 passes of full preset 13 encoding to understand which crf will fit into the specified size

svt-av1's rc is also bad, constantly overshooting or undershooting bitrate and max limits, even with some additional settings i have a lot of issues with that, when i tried to use svt-av1 for streaming for crf, probably some old methods with shorter sample encoding like it was used for x264 might work, but it really depends on the content and it's mostly svt-av1 issues, other encoders have much better rc

https://boards.4chan.org/g/thread/100031812

Maybe someone will answer at least there

ninibros...

?

<@1034873369314730065>2-pass crf has never exist

anywhere

^ this. crf is not trying to optimize for anything so it doesnt make sense to do more than one pass

it's almost useless for x264, somewhat useful for x265 but svt-av1 works differently, stats and analysis from the first passes are used and helps for better rc for next passes

this still does not solve the problem that I need to compress the file to the size limit

The question for specialists: is whether there is any software to determine the** information complexity** of the video in advance?

it looks like I AM will have to do full compression based on x264 ultrafast. create a video difficulty table based on the output. make a table of the recommended CRF for SVT-AV1 that will correspond to the size of the video in 1 hour of encoding with this complexity

<:kekw:808717074305122316> gread shit

yeah, but it's not about solving that problem, just that multipass crf for svt-av1 is not useless for encoding to exact size, piping works as i said, if needed a pure ffmpeg solution then not sure if it still works it's a ffmpeg implementation problem, but in general 2-passes work for svt-av1 for complexity, yeah this is pretty widely used and such metrics exist, but mostly proprietary solution, also fast first encoding as assistance for next encodings is also widely used

Okay. I'll have to do AOMENC tests before I fit into this shit

<:AV1:805851461774475316> There is a very big problem. parallelizability. In general, it can be solved if you divide the file into 2 parts, encode, and then stitch it into one but it is impossible to do proportional two-pass encoding in this way, one of the parts will always have much more bitrate than necessary

even for svt-av1

or even with a mix of different encoders including hw for first pass cvh

hah

Fun... AOMENC follows the documentation so rigidly that instead of the documentation of the encoder, you can read the documentation of the codec

Dzgas what about avm ottverse

I contributed on it this afternoon do you think they accepted something

<:This:805404376658739230> <:monkaMega:809252622900789269>

I'm still trying hopefylly Zoe Liu

Jxl d15

I corrected grammar

lie

https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Parameters.md from the table of all parameters, **[libsvtav1] Error parsing option** - 90% of all

how are you entering them?

the code in which each parameter that can be configured - was written by someone, BUT was not added to ffmpeg https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2021-July/281971.html

😕

what version are you running? svtav1-params has been in for a while

an extremely stripped-down version. with a couple of parameters, it was added a year later, after the code that I send above. And so

no, not use, absolute fuckin zero can be use

it's just not written in ffmpeg/libavcodec/libsvtav1.c

working perfectly fine for me [akkoshrug](https://cdn.discordapp.com/emojis/854355719109345280.webp?size=48&quality=lossless&name=akkoshrug)

<:BanHammer:805396864639565834>

what is your cmdline?

Are you seriously asking ?

yes

Im on ffmpeg 6.1.1-7 and it's working fine for me

also ffmpeg should say the config too, but if you have libsvtav1 it should be there regardless so im not sure why

No Do ```./ffmpeg -i IN.mkv -an -c:v libsvtav1 -preset 12 -svtav1-params scm=1:sg_filter_mode=1 OUT.mkv``` whitout *[libsvtav1] Error parsing option sg_filter_mode: 1.*

of sg-filter-mode=1

It doesn't matter, it's not implemented.

my svtav1 doesnt even have an sg filter mode

[Hmm](https://cdn.discordapp.com/emojis/1113499891314991275.webp?size=48&quality=lossless&name=Hmm)

isnt that quite old?

yeah, seems to be some deprecated option, but `-svtav1-params` works fine, been using for years without any problems

at the very least, the string isn't found in svtav1's docs

well considering how trash gitlab's UI is, I can't say for sure when it was removed, but it was removed a very long time ago at least

https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/CommonQuestions.md bruh

on with preset 1-4

it strongly eliminates the incorrect movement of blocks. I would like to include it for the gameplay of The Witness (game) - on the parameter encoding preset 8 - it would be much better. instead of encoding everything in preset 4

<:PepeHands:808829977608323112> 'll have to learn piping

im pretty sure thats hard coded isn't it?

I don't like it when make thing out like: it works if you work on it, and so we don't care about it.

you can always make a ticket on the svtav1 gitlab asking why its not configurable now

the problem is that this is a very bad situation. because ffmpeg & svtav1 does not work together — which of them is to blame?

and look this

there are a lot of non-configurable params that existed in some of the first versions, now it's just "optimally" distributed by presets and groups and it's like this is enough for the typical user <https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Source/Lib/Encoder/Codec/EncModeConfig.c>

the complete solution made 3 years ago has not been added to ffmpeg

But in pure svt av1 — you can

how old is your build?

from which version are these parameters?

I will study piping tomorrow <:NotLikeThis:805132742819053610>in fact, I set myself a big task, to choose the parameters that are most suitable for very fast encoding for games. after making observations for 2 weeks on all preset, I found out which ones specifically params can be turned off so that they do not take up the load

master <:WTF:805391680538148936>

it shouldn't be in it, if you are getting it shown as an output thats a bug

Are you saying that no more exist? I don't actually have svt, this is the print I found on the internet.

thats what we have been saying for a while

it's like some old or even pre-release versions that are 4-5 years old or something like that

Meh. Let me handle this.. after 30 hours, I'm busy right now

<:AV1:805851461774475316>

https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/CommonQuestions.md

and also ffmpeg works perfectly fine with svt-av1, with existing settings in current versions maybe just a few specific ones doesn't work

Not. it is impossible to use it due to the lack of a filter specifying the block shift and its separation. what makes the shaking of large blocks when moving at crf 50+ quality is completely removed only at preset 4 (1-4)

👉 bullshit

but to be honest, to compress the gameplay of aomenc — games is surprisingly full of bullshit. and rav1e is still a joke.

i'm just saying that the settings and encoding works, but not about quality

The absolute truth is that SVT—AV1 is better than AOMENC for game recording.

It is not settings, if cannot be configured, this is 1984

because it's a pre-release version, same thing for like a research aom build or current avm, with like 2800 different settings but when it's released, most of them will be non configurable

and most settings are not needed for normal people and encoding, but some are that's why forks exist that add back some settings or change some logic

it would be funny to know that this is all done so as not to debug their variations ||(not to work)||

Oh

Forks LULE

<:monkaMega:809252622900789269>

piping works like shit, and compiling a whole ffmpeg with a fork of svt-av1-psy (that is, just an classic script will not work) - no

I can't figure out this damn thing - how ```-svtav1-params enable-cdef=0``` CAN work if it's just not in the ffmpeg sources. only AOM has it

ok svtav1 can accept some parameters that can

https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Source/App/EncApp/EbAppConfig.c#L153

yep, other hardcoded

"just use preset 3"

It's only by rummaging through the source code that I find out about functions that aren't even documented anywhere. but which, unlike those functions described in https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/CommonQuestions.md -- They ahaha work in ffmpeg original <:kekw:808717074305122316>

As I understand it, I will be simple for the next 2 hours... although you know, this is a job for gemini 1.5

I did it. This is a list of all the parameters that can be used in ffmpeg -svtav1-params (generated by Google Gemini based on the source code)

👆 if someone knows devs, tell them that, in fact, the parameters that can be applied should be documented.

<@703028154431832094>

But you can confirm these options actually *do* something, right?

variance-boost-strength -- solved all my problems. it was added 3 days ago. the issue is closed.

It has been in SVT-AV1-PSY for a very long time now, if you want to check out our fork

just `SvtAv1EncApp --help` will give all the settings that should work almost, a few very specific ones doesn't work through ffmpeg

.

I've checked all the functions, here are the ones that do something or are useful

I don't think it is that hard ... Also most people use Av1an anyway

I saw that enable-qm is generally a useless thing that does smoothing instead of noise. what is not suitable for my crf 50-60

I disagree

At least for PSY

enable-restoration has the same problem

just need `qm-min`/`qm-max` adjustment

don't use its for gameplay of GAMES

Ah wait you're DZgas, there is no reasoning with you. Good luck out there <:KekDog:805390049033191445>

Well, tell me the arguments or what? Don't you agree? Well, and will you do weight for your opinion?

low parameters do more information on low frequencies, parameters 15 = filter off

`enable-qm` is useful, for any bitrate and any content, with some tuning, for gameplay also, I have a lot of gameplay recordings

All I'll say is that default SVT-AV1 is tuned around faulty metrics & flawed testing methodology. SVT-AV1-PSY is not just "add back some settings or change some logic," it is a total rework of the encoder. so until you start using PSY, it isn't worth discussing this

instead of turning it on at 1080p. I'd rather turn it off and use 720p.

maybe there are some cases if encode something like that old examples like already low quality source from twitch to even lower quality but in most cases qm is useful, even for that, it can be worse on some static frames, but better on normal viewing, especially with some tuning for that content

and yeah, it's much easier with svt-av1-psy, even with default settings it will be much better than vanilla but, additionally has more freedom to tweak things, even for blockiness issues, like: `--enable-dlf 2 --qp-scale-compress-strength 2/3` maybe `--sharpness 2`, `--tune 3` etc piping is not that hard, it's almost the same, same encoding speed, the only difference is that there is no auto-muxing for audio and other tracks, which would require some extra effort without using av1an or some gui or custom scripts

.

I don't have any more problems.

even at preset 12

`Tune 3` has a weaker tf, which can also help against blockiness and blurriness, without some efficiency loss as with completely disabled tf, also has Luma Bias in the test branch

on this example, maybe, but other issues are still there in vanilla version and vb also came from svt-av1-psy

also, very weird defaults ```enable-qm | ENABLE_QM_TOKEN | 0: off, 1: on (default) fast-decode | FAST_DECODE_TOKEN | 0: off, 1: on (default)``` because ``` --fast-decode Fast Decoder levels, default is 0 [0-1] --enable-qm Enable quantisation matrices, default is 0 [0-1]``` for vanilla svt-av1

gemini problem.

and cdef params

yeah, using ai for better settings or figuring options, even in sources, is not a good idea

Yes. developers should do this.

`SvtAv1EncApp --help`

too hard

this is such a massive understatment its absurd

anyone who relies on any LLM for this stuff now, or any time in the near future is an idiot

🙄

Don't worry, you won't have a job soon.

LLMs can't even do basic math questions and you're asking it to be reliable for this. That's just dumb.

and ffmpeg never had all the advanced settings in the encoder help, same for x264/x265, aom and other encoders, there are only basic ones x264 once tried to port most of the settings in ffmpeg arguments, but it's still not all other encoders mostly didn't even try it the same about docs from devs, most are outdated or incomplete, `help` from external encoders is the most updated and relevant

can.

https://tenor.com/view/laughing-hard-lol-lmao-oh-wait-youre-serious-let-me-laugh-even-harder-gif-16553942

<:KekDog:805390049033191445> I can tell you that you certainly won't

Testing copilot for boilerplate generation was one of the biggest eye openers i've had

obviously, you didn't understand this topic at all. although 2 days ago, together with a friend, I merged neural networks that were selected according to my tests, creating the most brutal and uncensored neural network - it's fun. https://huggingface.co/DZgas/GIGABATEMAN-7B but <#806898911091753051>

I understand it crystal clear

i've done immense testing

they are shit

Especially code related AI

You don't have enthusiasm. do that. whatever you want.

I have lots of enthusiasm

ok. try my neural network 🥂

Im not about to waste my time trying something I have significant doubts will be any decent

new llama passed the watermelon test

it can do math

you look like an anime guy who says that all new anime is shit (not looking at anime for 5 years)

freedom in neural networks is much better than its strength in tests

good for you, I mean, I didn't think you needed glasses before but now I do

Orignally I was tinkering with https://github.com/TabbyML/tabby maybe ill try it again with whatever new model this is

zero faith it won't land under actively detrimental like all the rest though

why are you so negative about it

chill

I get it you hate progress

No, offense, but this is a really retarded comment. If I was actively trying it out, why would I be against it?

Why am I negative about it? Because generally just, they're not really that useful. Does that mean I hate progress? No, I'm actively trying them out...

also whisper is bad today lmao

Auto complete and gesture typing is a good use of this type of AI

You get it when you enable data improvement in your phone keyboard

For the time I had GH copilot, it was also good at auto complete

nobody is telling you to use it to do your entire job

Just like how calculators and computers didn't replace people doing math and office work

LLMs have potential. but when it comes to coding they are rarely any better then just the standard tooling you already have, On the other hand, I've been seeing a lot of really trash LLM code that's been comming

Originally I was really excited for LLMs since a lot of the work I did was **heavy** in boilerplate crap, And I still think LLMs will be good for that *one day*

but I have significant doubts that one day is anywhere near

I think we're already past that

GH copilot is already good at that

yeah I have to significantly disagree

have you tried it

yes, it's actually what made me go out and try tabby in the first place

GH copilot?

yes

https://code.visualstudio.com/docs/copilot/overview

For me it did boilerplate pretty well

And I also used it with elixir

Perhapps it is very language dependent. I tried flutter(dart) and rust. dart I didnt have high hopes for since there isn't really a load of open source stuff availible for it to have learned on, but on rust I did. Both were subpar at best

well subpar is hard to define as of now, so let me correct myself, both were actively wrong in most cases and produced code that was no where near close to usable

I didn't expect much from it but it was pretty quick as a replacement for the normal auto complete

both rust and dart's tooling around that is pretty good already I suppose so it's a fairly high bar for that. I suppose it could be a case of that. perhaps languages with less optimal tooling like C/C++ could fair better

how much were you forcing it to generate for you? The normal use is supposed to be like 4 words completion

I'd say my elixir use was an even higher bar than those two

or maybe it's because most elixir code is higher quality

https://trac.ffmpeg.org/ticket/4907 Support decoding animated WebP images open enhancement 9 years ago

but they do support encoding for some reason <:kekw:808717074305122316>

https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=11521

a page with multiple animated webps is ressource consuming. sometimes its smarter sticking to gif

2 days old 0.o

SVT-AV1 surpassed AOMENC With this new parameter. I have completely removed the use of CRF now set crf=63 and enable-variance-boost=1:variance-octile=1:variance-boost-strength=2 and use Only variance-boost-strength for quality set 1 low 2 medium 3 high 3 very high

<:monkaMega:809252622900789269> enable-restoration=0:startup-mg-size=4:enable-qm=0 and we are getting the best that AV1 has to offer at the moment. It is much faster and much better than any aom parameters.

670 kbps video. like 360p on twitch ```./ffmpeg -i 1_1927833401.mkv -vf "fps=60,scale=1280:720:flags=lanczos" -c:a libopus -b:a 65k -apply_phase_inv 0 -frame_duration 60 -vbr on -c:v libsvtav1 -crf 63 -g 600 -preset 6 -svtav1-params lookahead=120:tune=2:scm=1:irefresh-type=2:enable-cdef=1:enable-dlf=1:enable-mfmv=1:enable-qm=0:enable-restoration=0:enable-tf=1:enable-tpl-la=1:fast-decode=0:enable-dg=1:startup-mg-size=4:tile-columns=0:tile-rows=0:enable-variance-boost=1:variance-octile=1:variance-boost-strength=2 test-W_1.mkv```

There are no blocks artifacts no error with movements blocks no blocks quality noise

it's just works <:This:805404376658739230> 👉 🥂 <:AV1:805851461774475316>

yeah and SVT-AV1-PSY is even better, you'd know if you could handle piping with FFmpeg :)

idk, i compared aomenc with svt-av1-psy with all the bells and whistles last week and it was still 10-20% behind

on slowest presets or behind at the same speed? btw, for svt-av1-psy `preset -3` is the slowest but, for me aom is still more consistent in quality on average, especially with forks, also works well on all rc modes like capped crf, cbr, vbr, multipass, etc svt-av1 is not good except for crf, even capped crf is mostly broken and even the recently merged vb has brought more issues with capped crf

rav1e chads sitting in the corner with hoods uo happy as ever

and for rav1e, all presets except the slowest ones doesn't exist <:kekw:808717074305122316>

very true

and 10-20% difference is a lot, svt-av1 is worse on some content, but not that much, not by metrics nor visually also usually faster with about the same quality, if not using the slowest presets, even with chunking

it was svt-av1 at preset 0 vs cpu 2

svt-av1 `mmx |sse 1x sse2 |sse3 1,32x ssse3 1.44x sse4_1|sse4_2|avx 5.3x avx2 |avx512 6.9x`

When encoding a JPEG at q=100, why do programs bother writing separate quant tables for luma and chroma when they're identical.

Is this a reliable test? http://littlesvr.ca/apng/gif_apng_webp.html

It concludes APNG is better than GIF and lossless/lossy WebP in terms of the compression ratio

In principle lossless webp should be able to quite consistently outperform apng since it also pretty consistently outperforms regular png — but probably there is a tooling issue and you cannot easily "literally" translate apng to lossless webp.

In any case, video codecs should generally be a better choice than image codecs for anything video-like.

Removed the description about APNG being smaller on Wikipedia

If 32bpp APNG is converted to GIF, it's possible the GIF will be smaller, because GIF is limited to 8bpp.

The original sentence was just too arbitrary and I had been feeling wrong for long time > In a comparison made between GIF, APNG and lossless WebP, APNG had the lowest file size.

When I was attempting to create an optimized APNG, it was quite tricky. I couldn't find a tool, that would optimize the animation by storing only differences between the frames and at the same time use the lowest possible color type.

Isn't optimising all PNG files before assembling them into APNG, a workaround? And storing only differences is the job by video codecs

The most important usage of animated images is making stickers

Assembling already optimized pngs is not straightforward. All frames must be the same color type, only one palette chunk and one tRNS chunk is allowed in one APNG file. Storing only differences is a common trick used in GIF. The frame contains only new pixels and the rest of the frame is transparent.

Is that "trick" doable for JPEG XL?

This trick is doable in APNG, WebP and JPEG XL.

They all support stacking frames with transparent parts.

I've been using the tools from here as an intermediary between GIF and JXL due to unspecified blend types erroring most GIF files I try https://apngasm.sourceforge.net/

Generally just using gif2apng, or apngopt on existing files, both cases it uses palette and inter-frame compression

I think I tried one of these but I probably misunderstood it. I will give it a try. Thank you.

I revised the description about APNG included in the 3rd edition of PNG spec on Wikipedia. It's now at the candidate recommendation stage

https://www.w3.org/standards/history/png-3/

The previous edition was published 20 years ago

I was curious how nonstandard RGB encoded JPEG really is and I found out that early versions of Internet Explorer and Netscape Navigator do support RGB encoded JPEG.

<@688076786525143117> i am curious how it works too, can you give me a TL;DR or a link to a resource?

There is no color transform between RGB and YCbCr, RGB components are encoded directly. Chroma subsampling is not used. The file begins with APP14 Adobe marker instead of JFIF. IJG cjpeg can produce RGB jpegs, so feel free to experiment.

that makes sense

cant be too efficient i'd imagine

thanks!

Indeed, RGB encoded jpeg is less efficient.

Only 42 stars https://github.com/w3c/PNG-spec

Huh, the end of this comment almost sounds like re-inventing JXL. XYZ color space for perceptual encoding, LZ77 compression, variable bitdepth per channel... https://github.com/w3c/PNG-spec/issues/426#issuecomment-2053779660

> The following features are out of scope, and will not be addressed by this Working group. > Changes that will invalidate existing files, editors, or viewers that conform to Portable Network Graphics (PNG) Specification (Second Edition). 🤔 https://www.w3.org/Graphics/PNG/png-2023.html#scope

The mention of 'PNG2' is... Hmmm

If PNG 2 were a thing it would be as vivid as WebP 2

The person who mentioned "PNG 2" is the top editor of PNG spec 3rd edition

Oh don't forget that they've been charted for the 4th edition as well

PNG at this point can only add stuff that will gracefully degrade, like new chunks that can be ignored by naive decoders. Adding stuff like new compression methods or pixel formats is just going to break existing decoders completely and if you do that, you can just as well make a completely new codec from scratch.

yeah, minor improvements doesn't make sense for breaking compatibility png is widely used because it's compatible i think even a new purely lossless format doesn't make sense either, if it's something new it should be a lossy/lossless format that is better than the existing ones and if it's going to be worse than jxl it will just make confusion with the same name and fragmentation and won't bring something useful why not just use jxl or add some extension for jxl (if jxl features are not enough) and promote it as a "new png" as well

As a container format, ISOBMF and PNG are quite similar: both have 4 byte box/chunk names and 4 byte payload lengths, and are otherwise just a concatenation of boxes. The only difference is the obligatory CRC in PNG, which, if you ask me, is a historical mistake that is solving a data integrity problem at the wrong layer.

Unless they want to violate that "PNG Working Group Charter"

Those labelled backwards-incompatible shouldn't be implemented either

yeah, some changes can be useful, which are backwards compatible and png will at least be decodable even on old decoders, without some extra features, but decodable other than that I don't see how it is useful for users, it looks more like some group just wants to take control and promote some format instead of cooperate with any of the modern formats (because there might be different visions of the design direction)

Not that significant and it's almost done https://github.com/w3c/PNG-spec/blob/main/Third_Edition_Explainer.md

Some changes may have existed for years

XYZ for perceptual compression strikes me as somewhat naïve / misguided

and using it indeed doesn’t guarantee the absence of imaginary colours

(X=1, Y=0, Z=0) is an imaginary colour because you can’t stimulate X without also stimulating Z

https://en.wikipedia.org/wiki/File:CIE_1931_XYZ_Color_Matching_Functions.svg

(this is why the spectrum locus is a slanted horseshoe on the xy chromaticity diagram)

ive messed around with different color spaces quite a bit and in my opinion effective compression isn't achieved through 'perceptual color spaces.' simple YUV is perfectly fine

the reason being the color space needs to react well to compression, reducing the bit depth in the channels

and it's less about matching human perception and more about removing the correlation between channels because spatial compression is where the real savings are (in terms of image compression)

no, it's not...

I mean, if at least luma was somewhat perceptually uniform... since it's not we get way lower quality in dark areas than bright ones with simple lossy SDR compression.

It makes a huge difference.

Yeah i agree. That aspect needs work. Im no expert, i was just giving my opinion based off the little experience ive had

Maybe srgb intermediates?

how do you mean?

The simplicity of PNG allowed it to be usable even on 486-class computers.

There are PNG viewers running on DOS.

Hmm not too sure but if we could figure out how to get the compressed aspect of srgb into a yuv style color space that would be great

Since srgb gives more bits to dark colors and less to bright

It does so more compared to linear (which all OETFs do), but virtually all other relevant OETFs do so even more.

The sRGB OETF is pretty much the worst common OETF out there, from a perceptual uniformity standpoint.

Oh interesting, that’s good to know. Btw nice to meet you, you’re an expert in color?

sRGB models how CRT monitors work, not how the human eye works.

YUV models how color TVs managed to introduce color in a backwards-compatible way in the 1960s, not how humans perceive color

Oh, just moderately so. I think I have a decent grasp of what types of colorspaces exist and how conversion between them works in principle. But I haven't yet delved deeper into the math, except for transfer curve conversion, which is a much more simple concept.

Chroma subsampling models how the bandwidth allocated to UV was lower than that for Y because broadcast bands were already allocated and there was little room left for the chroma signal

A lot of the stuff still used by image/video codecs today are effectively legacy nonsense from many decades ago, with more technical transitionary rationale (new stuff always had to remain 'compatible' with the existing old stuff) than actual perceptual motivation.

Yeah im not claiming any of these are based on perception

Yuv does have the convenient property of separating brightness from color which indirectly helps with compression

In terms of HVS

But that decision to reduce bandwidth of chroma was based on HVS

Right, this is most essential for good lossy compression, and also makes the colorspace more perceptually uniform.

the world if yuv luma was 1:1 with brightness

damn it I don't have the picture, just imagine it

Partially. And partially because they had to work with the bandwidth available. These were the days of broadcast using analog radio signals, where broadcasters already had frequency bands allocated, so they had to basically squeeze the new color signal in the padding between the existing bands.