JPEG XL

agree to agree

all lossy audio codec is coded only 20 khz maximum I know the vorbis can higher on maximum bitrate

There's "Master Quality Authenticated" that Tidal uses that goes up to 96Khz, because dogs deserve music as well

MQA is a scam. It is lossy audio compression.

Yep, only ever seen it promoted by the same types that promote wooden volume knobs and special USB cables

Best one I've seen was somebody accidentally using their special audio USB cable with their printer, and swore the print quality was improved

https://www.tomshardware.com/news/nvme-ssd-for-audiophiles

<:kekw:808717074305122316>

My uncle is a sound engineer, so when he wanted "deeper, richer sound" he just built himself an analogue amplifier, worked great (And looked great when it was on, he had the tubes extend through the lid of it)

audiophiles are always fun like when you re-encode lossy as flac and send them "lossless" and they can't tell a difference

my dad's like that and when he asks if my music I'm playing is lossless I just lie and say "yes"

since to him, he's still cemented in this idea that lossy is like 128 kbps mp3s from the 1990s

what I find funny is when they try to analyze the spectral content of a flac to determine if it was re-encoded from a lossy format but only signs that only apply to shitty mp3s and literally nothing else.

https://vertigo.ai/focus/ ML-synthesized face-only video codec coming near you

(a further discussion at the orange site: https://news.ycombinator.com/item?id=31516108)

it is no question that something like this is absolutely possible now, but well that feels like a turning point

i can hear difference between harshness of some of noise in some of tracks i listen to when stuff is encoded in lossy & lossless way tbh

nowadays just getting flac if i can get hands on it because of authenticity but otherwise anything else is fine

> i can hear difference between harshness of some of noise in some of tracks i listen to when stuff is encoded in lossy & lossless way tbh only if you're using pretty bad lossy compression or too low of a bitrate.

I don't see the problem with this. it's pretty useful to tell if an upload is sus, esp. when compared to different versions

and it works mainly because of the hard lowpass of all lossy codecs

https://www.reddit.com/r/marvelstudios/comments/uy7281/the_cgi_wasnt_improved_disney_just_uses_a_little/

Well that's interesting, low quality video encoding stripped a lot of details from the image, making the CGI seem worse

Smoothed the entire image, making the skin look like plastic

this is what modula lossy do?

can i add this to modula desciption

on wikipedia it jpeg xl

Apparently there are still people discovering YouTube for the first time.

No, lossy modular atm just quantizes squeeze residuals.

the issue is they go the other way and argue stuff is lossless because those signs aren't there.

I've only seen them being used to report uploads

I'm mainly bothered by "they" and the term audiophile and how it groups together very different types of people including musicians and audiofools

this is kinda like internet racism

I expected some detail loss, but not to that extent, guessing they didn't take green skin tones into account when designing it 😀

Someone's logic: streaming = always CBR <:KekDog:884736660376535040>

*nitrate*

Actually read it like that and it confused me at first

Apparently it was his autocorrect doing that XD

<:KekDog:884736660376535040>

i think the issue is the association with streaming (method of downloading) and streaming service

webp algorithm 6 (maximum) and avif speed 10 (minimum) Encode in same time but webp looks better<:banding:804346788982030337>

for thousands arts this is the best choice (for obvious reasons jpeg xr with the same speed cannot be used)

perhaps it would be even better if DCT was cut out of the encoder

just.....

how good the image would compress if we didn't use DCT I think it would be a great competitor in WEBP with quality below 40

The official 3D-HEVC SVN builds site's down Any idea where I could find the reference encoder? (wayback machine got nothing) http://hevc.info/3dhevc

Is it part of the general HM reference encoder?

I think Fraunhofer hosts it somewhere

oh no, sites are trying to serve animated avif and breaking on firefox

there's no way we could've seen this coming...

any examples?

https://bugzilla.mozilla.org/show_bug.cgi?id=1686338 comments mention hashnode and kickstarter

apparently kickstarter shipped a fix but it sucks cuz firefox is the one behaving incorrectly

has the ship completely sailed on getting a separate mime type for animated avif?

For things like Cloudinary f_auto, we can look at UA and avoid animated avif on firefox even if Accept: says it can do it. But for people stuck with srcset, that doesn't work (except with js trickery I suppose)

<@794205442175402004> I'm about to open a feature request to add JXL support to https://github.com/gkv311/sview What would you recommend for me to send the dev? (API reference, source, documentation, etc?)

just a pointer to the libjxl repo is probably enough, I'd guess?

👌

just little funnky

What is that scale? 5 ABCDF?

The Tier list

higher - better

purely subjective

Just strange that 5 is best (or is that an S?) and that E is missing

8 bits, 4:2:0, I guess that person should visit an ophthalmologist.

it's an S

in such cases, also all human

webp gives maximum quality at its very fast speed, jpeg XR is a little faster but noticeably worse in quality, it seems that only now I understand why jpeg XR did not distribution at all, it came out the same year with WEBP and in all tests jpeg XR is loses, this interesting jpegxr will only WIN from higher quality than webp q100 for jpegxr it is q90 and higher

yuv444 also goes to this

alas, but it supports all versions of Windows for 10 years already

<:Windows:806135372298977342>

https://vxtwitter.com/emilyst/status/1536482215823314944

I'm not at all sure that AVIF animated can replace GIF because of its gigantic decoding requirements At the same time, the '"ideal"' gif replacement that I see more and more often is WEBP - it can only do it in yuv420, which is not good, it's such a vicious circle. What is best so far is the use of AVC high444 with fastdecode

does jpeg xl have plans to replace gif? all technical possibilities are available

don’t forget webp lossless – might be appropriate for some gif-like use cases

I still use JPEG XR for photo album specific compression can describe specificity An original 3000x4000 photo is reduced exactly 4 times using Hanning interpolation. after which I use JPEG XR yuv444 compression at quality 95 and using all the "lapped biorthogonal transform (block overlaps)" - which down the encoding speed, but in 2022 it is super fast (2-3x fasted than webp) 1000 photos 750x1000 are compressed in just a minute. This results in a final size 0.3X of png. With minimal pixel differences, an almost exact perfect match. original png | jxr | jxr file

even if you look at the pixels "under a microscope", the differences are hard to notice

yes, I forgot that webp contains 2 different codecs

What gigantic decoding requirements? lmao.

very subject on the content, but about 10 times more than AVC

For very small systems are any modern formats suitable? Or are you just limited to uncompressed maybe with some RLE?

Are you sure about 10x? That is for raw reference decode, I would not be so sure for optimized implementations.

It's like 50x harder than vp8

on a single arm cortex a8 it makes a difference between useable and not

although that's encode :>

https://managedserver.it/webp-o-avif/

i forgot the translation

🍕

🍝

My poor CPU.

What do y'all think of farbfeld format?

can be thought as a PAM but with a profile, nothing special

farbfeld claims it's "easy to compress", which I hardly agree

Screenshots are kind of the best case for general-purpose compression

does it even have a profile? the webpage says: > The RGB-data should be sRGB for best interoperability and not alpha-premultiplied.

I meant that it's a strict subset of PAM in terms of capability

oh

A good heuristic is that if something is associated with Suckless, it probably sucks.

there is some truth in the so-called suckless philosophy, but the org itself is honestly meh (and better discussed in <#806898911091753051> )

Haha dont use vp8 vp9 realtime mode is better

non-progressive Wait the jpeg xl

yes, I also did tests with screenshots of the minecraft game, (the original without any kind of anti-aliasing or other) and loseless webp was also the best, more than 2 times better than png with optipng

I compressed a few hundred old Fallout 3 screenshots I had and JXL was the clear winner for them, it all depends on the content and functionality

Like even though WebP also beat PNG by a large margin I kept them as PNG because it's much better supported by software

I only now realize that rav1e is a pun on a French word

huh?

> **ravi** (*feminine* **ravie**, [...]) 1. thrilled, overjoyed, delighted, ravished, chuffed

I never noticed, lmao

added to italian av1 wikipedia

uh, not sure if it's a good thing to add, especially if the etymology is not given by authors themselves

Yeah. It means Rust AV1 encoder, nothing else.

fixed

Rav1e contributed by Xiph and some Mozilla employeers. The latest version is 0.5.0. Xiph.org also created rav1e, an encoder written in the Rust language, described by its authors as the fastest and most reliable of the AV1 encoders, fast enough for real-time WebRTC streams. Rav1e means Rust AV1 encoder.

still rude

i don't work for mozilla

and i'm talking to their business

how i could correct this

https://it.wikipedia.org/w/index.php?title=AOMedia_Video_1&diff=prev&oldid=128108275

small edit

are you a rav1e author by any chance?

It _means_ Rust av1 encoder, but I kind of assume one of the rav1e devs knew and didn't mind that it's also the french word for "delighted" in the feminine form

I've always pronounced it as "rave" <:Thonk:805904896879493180>

<a:BlobRave:821042690070020106>

<:CatSmile:805382488293244929>

No, but I am a frequent user and contributor for it.

** AVIF Baseline Profile** Uses AV1 Main Profile AV1 level is 5.1 or lower Level 5.1 is chosen for the Baseline profile to ensure that no single coded image exceeds 8K resolution, as some decoders may not be able to handle larger images. More precisely, coded image items compliant to the **AVIF Baseline profile may not have a total number of pixels greater than 8912896**, a width greater than 8192, or a height greater than 4352. It is still possible to use the Baseline profile to create larger images using grid derivation. ** AVIF Advanced Profile** Uses AV1 High Profile AV1 level is 6.0 or lower Coded image items compliant to the AVIF Advanced profile may **not have a total number of pixels greater than 35651584**, a width greater than 16384, or a height greater than 8704. It is still possible to use the Advanced profile to create larger images using grid derivation.

i'm just confused because I thought that the AVIF limit had been break, but it turned out, and I did not know this, that the limit was the number of pixels.... It was not logical for me because the **webp **was limited to 16384x16384 specified to 14 bit vp8 coordinates

there are definitely people here who should know **Where can I find AVIF tests** for different speeds setting I made this picture in paint for myself by running 2 pictures on 2 different cores with parameters min 50 max 55

now understand why the default speed is 6

I don't know of many real subjective experiments that tested various speed settings of various encoders (since that quickly gets expensive to test). I have some results on aom s7, aurora speed 'faster', aurora speed 'slow' and some very limited data on aom s1

Generally slower avif speeds tend to be a bit better overall, but also more inconsistent in the visual quality that you get

There is no real limit, that just exists for hardware decode.

If/when a major deployment starts using hw decode (say Apple, who do that for heic), it might become a real limit

Hopefully they have a software fallback.

uh, so not even the advanced profile can encode a full-resolution photo from a Canon EOS R5 (45MP) or a Sony α1 (50MP) without the grid hack?

Only a problem with hardware encoders in this case.

These profiles are meant mainly for video levels and HW decoders.

For still images, I think cameras are the _only_ use case where hw encode/decode makes sense...

I'd give a case for textures and such, but they come in their own formats anyway.

Yes, texture formats are another beast altogether... Those need to be decoded every frame (so 60fps or whatever the refresh rate is), so even with hw decode, I don't think avif would be suitable for that

(it would basically be like using av1 intra-only at 60fps)

Texture formats need to be natively handled by the GPU to work, so yeah nope.

Wonder if there's any way to make this PNG smaller <:thinkies:854271204411572236>

<:KEKW:643601031040729099>

But now it's not a png anymore <:Cheems:884736660707901470>

oo, how'd you make it smaller? I did `cjxl -d 0 -e 9 -E 3 -I 1`

I also used -g 3

``-e 9 -q 100 -I 1 -E 3 -g 3``

ah

But wonder if there's a PNG optimizer that can actually make the image smaller than the PNG above. Used ECT with extremely slow parameters and guess I can't get it any smaller... or at most a few bytes, but then I would have to wait for days or weeks <:KekDog:884736660376535040>

short of handcrafting something probably not, I used my own script and it didn't help

Hm, think ECT tends to get smaller than what you used

it seems to me that no one wants AVIF to be used for this, it is very expensive

in fact, I understood the complexities of AVIF literally now, when I manage a compression project for about a million comic/manga images, I made test 1000 images, and when I opened the folder, I saw a terrible sight - decoding pictures to create previews of about 10-20 pieces per second, while for WEBP It is over 500. Another bad indicator is the instantaneous opening of about 400 AVIF images in the browser in one window, ohh this is just bad. not good for anything. I had to decide to use WEBP for this project, on the quality of WEBP q75 it did not fit into the weight framework, so I had to reduce the size of the pictures on the larger side to 1280px, which in general is not so bad for eye.

but, there is good news, when Resize AVIF to ~256x256, all bad disappear. so I use this option for a preview about 4-5 kb and loading 1000-3000 previews in one browser window

at this size it is also perfectly possible to compress using the entire maximum AVIF -s 0

but still, no kidding, about 5% of everything is HEAD of heic which is a little annoying that it is about 200 bytes, despite the fact that img is 4000 b

alas, jpeg xl is not even supported in the browser, given that it has progressiveness, there will be no problem with the preview. but how much faster it can be "decoded" than AVIF - seems to be a good question AVIF vs jpeg xl decode TIME

JXL's VarDCT mode is much faster than AVIF apparently, even before progressive decode is considered

modular mode is magnitudes slower in my experience tho

^ yea, tho apparently there's a bunch of WIP ideas to make it much faster

but the devs are prioritizing on preparing for 1.0 before they improve speed

🙏

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

👍 But like every year. Let's keep going until jxl released.

On my computer, AVIF decodes slightly faster than JXL. For example libavif is much faster when built with libyuv (using dav1d decoder is not enough). I also feel that libjxl accelerated after 0.6.1 version.

if your'e still using 0.6.1 then that does not surprise me

I will definitely say that AVIF is so slow in decoding that it is strongly not recommended to use it in projects with a lot of reading pictures, but in original idea, when users load the page in the browser and decode it, this is exactly what is good. trying images with 60000x3000 (just web manga) - it's very slow decode time (my is 5-10 sec)

simple switch the image already becomes a kind of problematic

Oh, it is Korean manga says Manhwa

I wanted to say that this size is noticeably long decoded. I'm more concerned about a lot pic of medium sizes.

I thought Korean webcomics typically split a long vertical image into multiple segments in general

i thought so too since that resolution is troublesome for every format

can often be manually

yes, that's my impression

https://static2.risens.team/Manga/8357/01.jpg

yep

My friend compiled (for windows) the most powerful JPEG encoder from google - guetzli in unlimited mode. so that I check the minimum possible quality that it can produce

png

minimal q0 (same q75 in guetzli)

10 kb

avif 10 kb

it's funny that guetzli works as much as AVIF at the maximum parameter Speed - 0

avif 3 times less (3.2 kb)

https://www.coywolf.news/webmaster/safari-now-supports-avif-in-macos-ventura-and-ios-16/

I wonder whether they support HDR in AVIF as well

I’ll have to try

https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_12_15/index.html#abandoned-packard-automobile-factory-detroit-200*1:1&AVIF-AOM=s&JXL=s&subset1

Why does AVIF look ugly as sin in these comparisons

With hugely evident macroblocking

In the sky or in any gradient pattern

HEIF consistently looks better

Jxl handles gradients the best probably because of the xyb color space

compared to...?

Avif

Does avif normally have such bad artifacts?

probably not as much with at a slower preset

but it seems like these are all default presets for speed

neither avif or heif do very well on the comparison you linked 🤔

Funnily enough, tried avif once recently and anything below s 4 looked worse than s 4...

what is the default now, still 6?

Had worse blocking for whatever reason. Really glad at least jxl is very consistent and easy to use. Another issue I have with another format: webp being extremely inconsistent with lossless file sizes. I have an image where 4 outperforms every other speed XD

I honestly have no idea, but defaults in avif is meh ish

Kek, I'm going to show up late for therapy, because I'm waiting for the last image to finish <:KekDog:884736660376535040>

More reasons to buy a high end Zen 4 CPU maybe soon ish <:thinkies:854271204411572236>

Dragging that webp into the Discord client made it crash XD ~~it's stuck on processing, but frick Discord and it's never ending issues, at least this is the difference between file sizes before I show up even later for therapy XD~~

<:PepeGlasses:878298516965982308> let's talk more about this

how does waiting for an encode make you feel

Annoyed <:KekDog:884736660376535040>

Old comparison with old settings really.

I mean, decoding complexity of 8-bit 4:4:4 all-intra lossy AV1 through dav1d is still quite a bit faster than JXL on a Zen 2 3700X ST. Comparing 10b 4:4:4 to JXL however, djxl seems to be on par and even slightly faster than dav1d, both at similar high complexities(-s 2 for aomenc, -e 9 for cjxl): ```time avifdec -j 1 --info /home/bluezakm/Pictures/2048x1320_david-marcu-441_png_original.avif Image decoded: /home/bluezakm/Pictures/2048x1320_david-marcu-441_png_original.avif * Resolution : 2048x1320 * Bit Depth : 10 * Format : YUV444 * Alpha : Absent * Range : Full * Color Primaries: 1 * Transfer Char. : 13 * Matrix Coeffs. : 6 * ICC Profile : Absent * XMP Metadata : Absent * Exif Metadata : Absent * Transformations: None * Progressive : Unavailable * 1 timescales per second, 1.00 seconds (1 timescales), 1 frame * Frame: * Decoded frame [0] [pts 0.00 (0 timescales)] [duration 1.00 (1 timescales)] [2048x1320] real 0m0.064s user 0m0.062s sys 0m0.002s [bluezakm@bluezakm-pc ~]$ time djxl --num_threads=1 /home/bluezakm/Pictures/2048x1320_david-marcu-441_png_original.jxl JPEG XL decoder v0.7.0 3b6cce9 [AVX2] Read 576852 compressed bytes. No output file specified. Decoding will be performed, but the result will be discarded. Decoded to pixels. 2048 x 1320, 45.63 MP/s [45.63, 45.63], 1 reps, 1 threads. real 0m0.062s user 0m0.058s sys 0m0.003s```What is extremely interesting however is that once an alpha layer is included, djxl seems to pull ahead by quite a bit, which makes sense since it can handle alpha layers natively, unlike AV1.

comparing 8-bit 4:2:0 doesn't seem fair

considering that it's half the data

Hence why 4:2:0 doesn't exist in my tests. 4:2:0 stays in the realm of video. Anything lower than 4:4:4 is not a good compromise unless at very low-low bpp.

For some reason a 16384x16384 image i encoded looked much worse in jxl than avif at high bits per pixel

Might be because the monitor i compared on is setup for gaming with all color accuracy thrown out the window and things like black equalizer on and digital vibrance cranked

The photoshop difference blend mode was still better for avif by a considerable amount, i however did only go up to -e 7 because it started taking 7h to encode

Jxl encoding is perceptual and uses a low nits target by default - if you're going to display it in a significantly different way, you should adjust the intensity target

Interesting experiment result. I tried upscaling a full-res 1080p3D (3840x1080) SBS video to half-res 4K (3840x2160), but despite the DOUBLE vertical resolution, the video quality on both local file and youtube is actually *LOWERED*. At least when comparing still frames, I'm yet to compare motion. My guess is that the upscale algorithm I used (Hardware NVENC + CUDA, the only one I found with acceptable encoding speed) inherently causes generation loss since the source is already lossy (despite 100MBPS bitrate) THIS is why absolutely *despise* multiple encoding passes and wish I could record + upload lossless, but the filesize of 5hr+ full HD 3D video is far beyond youtube's limits. So much for trying to cheat youtube quality lol

All lossy encoding is lossy. Unless you encode lossless, you will get quality losses.

how feasible is a lossless 4k 5 hour long video

> far beyond youtube's limits guess that answers it

True. do you know of any reasonably fast+high quality encoders that could be used to double the video height without losing (noticeable) quality like this? maybe kinda like bit-exact recompression used in JPEG->JXL, but for video and at least *perceptibly* lossless I tried a bunch of FFMPEG settings, even nearest neighbor, but they were either too slow even though they should (at least in theory I think) be faster than whatever NVENC/CUDA does.

<@288069412857315328> yeah, and youtube recommends 68MBPS for 4K60 video, which should allow around 8-9 hours tops <https://support.google.com/youtube/answer/1722171?hl=en#zippy=%2Cbitrate>

Not sure what is Youtube doing with videos. Many Youtubers are complaining that Youtube compression darkens videos so dark scenes are getting even darker.

I would try to set the pixel aspect ratio to double height pixels. That might trick the encoder.

At least it worked for wider pixels when I was uploading MPEG2 video (VOBs from DVD just joined to one file).

it converts to bt709, which might look wrong if the original had a wrong colorspace tag that the uploader didn’t notice because their viewer didn’t take it into account

This become kind of running joke on Youtube. People have no idea what bt709 is. They just blame Youtube for making videos darker.

what did you use to set pixel aspect ratio? that might just be exactly what I need 🤔

On DVD, the aspect ratio is either 16:9 or 4:3, so it was already set.

In ffmpeg, the -aspect argument can be used to enforce the display aspect ratio even in copy mode. It's not guaranteed it will work, but it's worth the try.

my recent experience with uploading a video with a funny SAR to Google Drive suggests that it might just work

although I don’t know whether it will affect youtube’s assessment of whether it’s a 1080p vs. 4K upload

i added fpnge to the embed bot ``` Comparison: bytes ips fpnge 4549535 2.67 :zlib 5590656 2.25 - 1.19x slower +69.72 ms lodepng fast 3464380 0.80 - 3.25x slower +867.32 ms lodepng 3407073 0.59 - 4.39x slower +1303.70 ms lodepng slow 3235623 0.105 - 25.49x slower +9187.29 ms```

...maybe lodepng on faster settings is better afterall...

on what corpus did you try it?

(and with what compilation settings/cpu?)

i had to disable avx2 and pext for fpnge

main concern was size, it was faster and smaller than the basic deflate, but i forgot i can change settings for lodepng

since originally that lodepng slow was basically unusable

avx2 spat out "double free or corruption"

yeah I think except if you just have a bunch of photographic content, lodepng's fast modes will just do better

that's not nice

I probably should fix that

and the system it was on doesnt support pext i think

do you happen to have the test corpus somewhere?

oh i just tested it on a single image

well, somewhere accessible xD

ah I see

it was mainly did it work or not

from the results you got I'd guess it's nonphotographic

is that right?

yeah

then yeah lodepng will definitely wipe the floor with fpnge 😛

if you try on photographic images it should do better

fpnge or lodepng?

fpnge

and if you can file a bug for the error you got, it would be great 😄

(I have been thinking about spending some time to add a couple of slower modes to fpnge)

(also, did you mean you switched from avx2 to sse4, or did you switch all the way to scalar code?)

to sse4

... curious

forgot to put the image for the bug..

that's so weird, the double free doesnt happen after doing it a second time, but does it again after doing a different image

needs some sanitizers xD

ok that's fixed

can you try avx2 again, out of curiosity?

seems to work now

here's the quick comparison in elixir ```fpnge 2.84 :zlib 2.38 - 1.19x slower +67.20 ms lodepng 0.51 - 5.52x slower +1593.63 ms```

what's the difference between sse4 and avx2?

``` Name ips average deviation median 99th % fpnge 2.70 370.80 ms ±1.62% 369.59 ms 393.73 ms fpnge -mno-avx2 2.57 388.93 ms ±0.79% 388.62 ms 397.32 ms```

uh, I expected more of a difference tbh

what's this measuring exactly?

just how fast it is in elixir using a single 4mp image (non photo)

and for 30 random images on my computer: ``` Name ips average deviation median 99th % fpnge 0.26 3.91 s ±1.96% 3.91 s 4.16 s fpnge -mno-avx2 0.23 4.31 s ±2.79% 4.32 s 4.53 s```

how many encodes are you doing, and are you sure you're not also measuring the input decode time?

is there a comparison of encoding times for jxl against others like libwebp, avif, mozjpeg?

it would actually be useful if someone could do such a test with current versions of everything and at various speed settings

various speed settings and various quality settings (say from d0 to d4 or equivalent)

and of course in case of lossless jxl, also fjxl should be included (it's a lot faster than libjxl e1)

suffices to test it on one largish photo and on one largish nonphoto, there'll be some differences depending on the exact image contents but generally it shouldn't matter that much

What kind of image classes would be good for a test? I suppose 1) Photography, 2) Illustrations, 3) Diagrams, 4) Document scans or PDF to PNG

illustrations and diagrams are not that different

and scans can be either pretty much like a photo or pretty much like a nonphoto, depending on how much denoising/thresholding the scanner/software has been doing

the thing I used counts as many as it can do within a time limit (I set 40 seconds) And the inputs are all decoded in memory

a bit weird then, oh well

I wrote some code for that at some point in the past (to make the fpnge/fjxl slides)

so, today I've claimed that JPEG XL can reduce CO2 emissions by the equivalent of 32 million cars, **and** it can reduce racism

https://twitter.com/jonsneyers/status/1550217374980358149

https://tenor.com/view/peter-mexico-bandera-de-gif-14309619

the racism aspect was an interesting take. ||I _think_ JPEG XL better preserves both facial details than AVIF and there seems no particularly worse artifacts for LHS, but this can be a bias by its own (human cannot easily see facial features of other races in general).|| (hidden in order to not influence the poll)

in case twitter recompression is messing with this (I don't think it is a problem here, I picked pretty low quality settings so things should be sufficiently worse than whatever twitter is doing), here are the files I uploaded to twitter:

oh, discord doesn't show the filenames when there's more than one file, it seems. The order is original, jxl, avif, jpeg

(so jxl and avif swapped compared to the twitter thread)

I normally wouldn't use such low quality settings but the effect is of course more subtle and harder to see at higher quality settings and I had to take twitter recompression into account

Also maybe I should have done the comparison JPEG vs JPEG XL and leave AVIF out of it, I don't want to sound like I'm trying to bash AVIF all the time... oh well

isn't that mostly a side-effect of humans having higher ability to distinguish luma in darker areas?

so codecs need to allocate more bits to darker areas since the artifacts are more visible there

and legacy JPEG doesn't, which hurts people with darker skin more than people with lighter skin

Speaking of AVIF, there seems to be no straightforward way to create AVIF animations. That's surprising, I thought AVIF animation would really benefit from it's video based compression.

The point of a transfer curve is to spread bit allocation in a perceptually uniform way

The sRGB curve just isn't a particularly good one, and doing things with limited precision (basically 7 bits only when doing YCbCr on 8-bit RGB) leads to these issues.

Yes, I think avif proponents should focus more on improving tooling for and adoption of animation. I think it is the biggest strength of avif.

Lol, now I know some developers who think webp's function is to protect media from piracy...

"Webp is made so people can't steal media and it's made so we can't use webp in our editing software"

That reminds me of professional photographers who like jpeg's generation loss as it helps to limit illegal redistribution...

obligatory xkcd strip about breaking use-cases

there is an actual approach to maximize generation loss as a watermark

https://micrological.appspot.com/cl-web/info09-jpeg.pdf

it's a good thing jxl can repack legacy jpegs so that these use-cases won't be broken!

https://www-gazzettamolisana-com.translate.goog/codec-multimediale-av1-sotto-inchiesta-per-licenza-antitrust/?_x_tr_sl=it&_x_tr_tl=en&_x_tr_hl=it&_x_tr_pto=wapp

english to italian to english translation

very good article one of the best

Generation loss as a copyright protection doesn't make much sense as in audio and video content, the right owners will claim their work even if the media is in very low quality.

soooo

if you do tests based on the "wave function collapse", then on the core my 10 years OLD cpu is about 30% worse than the analog at a price from ryzen 1, silent progress with nanometers and memory frequency, but there is video encoding, then my cpu without AVX in different codecs can be in 5 times worse

I buy some kind of dual-core Intel with AVX for $ 10 and at the small TDP (65 vs my 95) it is 2 times more powerful HEVC encoding than my atlon at the same frequencies and having 4 physical cores

but for example for AVC the different is minimal, maximum 20-30% and sometimes even on same. x264 encoder is not big avx optimaze (2003 technology yep)

I do not know a example when a program with AVX would work worse than SSE only

it would be interesting to see it in AVX

||Of course I didn't read it thread so I just talked to myself about things that everyone with the rating already knows||

8 kbps 1993 vs 2013

The opus codec has a hell of a non-intuitive markup of signal encoding blocks

i did tests and found the best number of bitrates after which came on the new block to stereo 43 kbps (minimum possible sound in stereo) no-phase-inv, music 87 kbps (LOW) no-phase-inv 105 kbps (MEDIUM) 141 kbps (HIGH)

opus encoder recommend 96 by default and 128 for maximum

<@688076786525143117> <@604964375924834314> finally got around to trying this but it doesn't look like it's working. it was hoping it would *at least* double the displayed height while retaining the resolution which would display 3D better on a TV and show the full thumbnail, but youtube seems to ignore the -aspect metadata even it works in VLC and MPC-HC

Have you tried both MP4 and MKV? Perhaps Youtube can't read metadata correctly.

I used MKV for the 3D metadata, which is properly detected by youtube to enable the 3D anaglyph view (and also 2D) option <https://youtu.be/cHnpQybMaL0>

cuz the thing is that the video resolution is 3840x1080 which is 2 16:9 frames side by side for a total of 32:9 aspect ratio. so I just want youtube to fill out the entire view without scaling AKA force display 16:9 as specified in the metadata

Perhaps Youtube needs the aspect ratio information to be set at the bitstream level, not at the container level. In MKV, it seems that ffmpeg will set the aspect ratio at the container level.

do you know any tools that can set it at the bitstream level?

I tried `-vf setdar=16:9` but apparently that's not allowed when using stream `-copy` so I'd probably need to re-encode the video, which kinda defeats the purpose of what I'm trying to do lol

use the bitstream filter h264_metadata

`-c:v copy -bsf:v h264_metadata=sample_aspect_ratio=1`

there's an equivalent one for hevc and av1

ignore that user

<@853026420792360980> unfortunately it seems youtube ignores that, too even though it also works offline like `-aspect`

<https://youtu.be/uCxi_PT7DCc>

btw are there any codecs/settings to do bit-exact recompression to upscale 2x1080p to 2x4K frames? especially if it takes a reasonable amount of time, it'd probably be the only good alternative cuz doubling the height alone requires re-encoding which introduces noticeable quality loss 🤔

even at a high quality setting ?

like `-crf 1` or something along those lines

if you use x264 with a very low CRF then you generally won't notice the generation loss

but the file will be very large

<@604964375924834314> <@853026420792360980> yeah, the filesize would be massive, especially considering the resolution would be quadrupled. not to mention, the encoding speed would probably also be sluggish, cuz the only reasonable one I found was NVENC CUDA hardware, and even that took more than 5 hours to encode. but I guess the concept of keeping the same image while quadrupling the resolution "canvas" so it's faster is probably just a pipe dream.

68Mbps would be the target, based on youtube's recomendation for 4K, and that's what I used here^

if your upload bandwidth and disk space allow then I would suggest targeting slightly below the maximum overall file size permitted (256GB) rather than the recommended bitrate

Avif is and has always been shit though as far as my eyes can tell. Always horrible macro locking like jpeg with bigger blocks

where is AVC and where is HEVC (left and right)

Are they different for each image?

Gunna guess hevc is on the right

That chroma subsampling is horrible tho

On both

They both look not remarkably different

If it's a pic of a blue sky the blocky one is avif

it just... hevc is SUCK. on 320x180 video and USE 5 more times then AVC - and it is the real same Quality pics! AVC placebo (TESA 64) HEVC placebo (STAR 57) im use my friend's Xeon and Encode AV1 speed 2 (same speed on HEVC placebo with me=sea) you can see...... all .... on hevc/avc is bad. AV1 just best on this SIZE (180p) .. . no one codec after AVC (vp8/vp9/hevc/ and other free) is not competitive on this Small size and bitrate

but the AV1 is finally best

<:AngryCry:805396146322145301> no. hevc is left

I recently came across a test where HEVC can suck even though it took 2-3 times longer to encode (vp9 obviously sucks even compared to AVC)

but according to my tests, HEVC was 5 or more times slower than the maximum possible setting that AVC can have and still it doesn’t win anything

<:H264_AVC:805854162079842314> in my humble opinion, HEVC is slightly clearer in non-sharp areas, but this is not enough, in my opinion, approximately, at most, an advantage of 10% <:H265_HEVC:805856045347242016>

<:AV1:805851461774475316> 16k <:AV1:805851461774475316> 8k <:H265_HEVC:805856045347242016><:AV1:805851461774475316> 4k <:H265_HEVC:805856045347242016><:AV1:805851461774475316> 2k <:H265_HEVC:805856045347242016><:AV1:805851461774475316> 1920x <:H264_AVC:805854162079842314> 1280x <:H264_AVC:805854162079842314> 1024x <:H264_AVC:805854162079842314> 720x <:AV1:805851461774475316> 640x <:AV1:805851461774475316> 480x <:AV1:805851461774475316> 320x <:Spam:806628077656473650> 128x

av1 but speed 3 is a little faster (0-10%) than hevc Placebo

(2 times faster than hevc me=sea or av1 speed 2)

Darker areas are easier to see because our eyes compensate and are better able to see the small differences in shading.

Brighter regions appear washed out and are harder to notice small variations in shading compared to light.

yes that is what I just said

Codecs are not smart enough in their psyvis model to take this into account

that is what I said yes

Except maybe jxl

I am agreeing with you :)

no need to repeat it back to me <:WeirdChamp:760032104422703134>

I think it is good for codecs to be smarter and more accurate fidelity based on taking into account real practical factors of the human psychovisual system like this

I don't think it is healthy to focus on an outlook of victimhood or to see racism and injustice in places like a quantization algorithm, or other inanimate things that were designed with the INTENT to benefit us all equally

I do however think that file sizes should have been shared in the comparison.

PSNR-based BD results are meaningless imo. PSNR is nearly unrelated to visual quality, especially with modern codecs.

only left channel (mono) ```opusenc --bitrate 25 --framesize 60 --set-ctl-int 4008=1103``` AV1 102x80 speed 0 (aomenc)

Not bad but I think AV1 could do a higher resolution as well.

how much SSIM better than PSNR?

SSIM like it is implemented in ffmpeg (single-scale, yuv) is not much better than PSNR

<:Thonk:805904896879493180>

Speaking of tiny video files, in Windows, there are little AVI movies used for animations in the UI. These AVIs are encoded using RLE compression and they have indexed colors. Kinda similar to animated GIF. These files are also very small, they are embedded inside DLLs.

<@604964375924834314> <@853026420792360980> looks like I had given up too early! we had the right command but the wrong value I needed to use -bsf:v "h264_metadata=sample_aspect_ratio=**1/2** to make this 3840x1920 video be upscaled to 3840x2160 on youtube's end https://i.imgur.com/nOJD8VO.jpeg https://youtu.be/Dka7CRrjMSY

so it's not doubling the vertical resolution, but at least it's doubling the height (which is what I needed for it to be properly displayed on 3DTV/VR)

I need comments from people who also understand the relevance and over the use of current video codecs

What codecs to use is imo mostly a combination of interoperability considerations and trade-offs between encode speed and density - where the optimal trade-off depends on the degree of asymmetry: netflix can afford ultra slow since they get millions of views per encode and latency doesn't matter, video chat needs realtime (both throughput and latency).

This is all explicitly, I asked professional specifics, the only thing that matters is which codec would be better to run on weak 2-core PC

on the graph, I show exactly the advantages of codecs, the moments when they are best

few people think that HEVC is absolutely no better(and sometimes worse) than AVC at low screen sizes at the same encoding speeds

no one compares VP9 at low bitrates to understand that they are worse than AVC, despite the fact that VP9 are many times slower

there are 4k video tests but this is not what I think is relevant...

well, if take only AVC and VP9 in this, then of course, there is truth here

to me the entire basis of using resolution in this case doesn't make any sense, vp9 being in medium speed also doesn't make sense as aomenc can get better results faster, placebo being there at all doesn't really make sense cause it's slower than veryslow with often worse results also in general svt speed 8 to 13 is a huge range and the speed of 13 is not comparable to x264 slow

people come up with too much nonsense about Placebo

ok well I am telling you as someone who has used it, it does often give you worse results metric wise and subjectively

This placebo bullshit is like they just say in math that you can't divide by zero.

the problem with placebo is that its use does only one thing(different from veryslow), it changes the way motion estimation is from UMH to ESA (or TESA) and the problem is that it does NOT increase motion estimation distance

I have no idea why this is done, but it can really worsen the result, and yes, the placebo mode is not the most powerful AVC mode

me_range=64 (maximum) mvrange=512 (or more)

on ffmpeg -x264-params

in fact, at the same speed, it is better to use me_range=64 together with UMH so there will be more efficiency in the same time me_range=16 TESA (placebo)

and as I discovered it works better than HEVC at the same speed (FAST-MEDIUM) at 540p and lower

there is still a sad fact, there are a lot of patents for the AVC codec, and all of them are available, you can see how everything is arranged, beautifully and clearly, but you can’t find this shit on new codecs, it’s very sad. no one draws beautiful pictures on AV1

I remember a long time ago I read that here in HEVC the search radius of vectors is not 16 like in AVC, the length is 64 (57) it's funny after this to drop away HEVC and switch back to AVC, yep.

(I mean that the maximum possible AVC at the same encoding Speed is better than HEVC)

(on a frame size not higher than 720p)

This is interesting but why is it testing only black & white videos?

I don't think there's much difference... But hevc will be better to draw vector differences by 1 bit color

I would expect the more recent codecs with chroma from luma etc to gain a bit more compared to h264 when taking color into account

it is... but i always do chroma_qp_offset=-2 (for film and -4 for animation)

AV1 does real magic with colors without settings

I hope when they add AV1 to telegram they will make the LEVEL 3.1 limit

and in the discord it would also be not bad, but it is unlikely that they will be interested here

I made a discovery, VORBIS is the best codec for music bitrate 16 and below

This is a complete defeat of the OPUS CELP codec in terms of sound quality

I can't believe what I'm hearing, but this is so much better...

interesting that of all the codecs, only VORBIS can make the "internal width" in any range

4000 hz 8 kbps Draven - BloodGod (feat. Dav Dralleon)

I notice that this is AAC-LC, perhaps HE-AAC is worth a try?

no, sbr can only 16+ kbps

ah

I'll more tests later

Simply, this is a test for the minimum possible bitrate at which it is real to listen to something, minimum for all this codec is 10-7 kbps

https://cdn.discordapp.com/attachments/308921309893623820/1003957967349096578/DZgas_music_tracklist.webm

<:ReeCat:806087208678588437>

neomelodic can't be listened at 8 kbps

Give a one

what vorbis encoder / settings do you use?

with --quiet --bitrate 168 --cvbr --speech --set-ctl-int 4000=2049 --set-ctl-int 4004=1105 --framesize 60 --ignorelength - %d

even opus improve

for %i in (C:\Users\Use\Music\a\*.flac) do ffmpeg -i "%i" -c:a aac -aac_coder anmr -q:a 1.344 -strict -2 "%i.m4a"

for %i in (C:\Users\Use\Music\a\*.flac) do ffmpegold -i "%i" -c:a aac -q:a 1.524 -strict -2 "%i.m4a"

comes near at youtube opus quality utilizing 436 kbps in a part

i encoded one time nicky jam ojos rojos from 24 bit and it came good on my mother's phone

but honestly i don't like this settings it sounds too flat on speaker

for %i in (C:\Users\Use\Music\a\*.flac) do ffmpegold -i "%i" -c:a aac -q:a 1.238 -strict -2 "%i.m4a"

is nice as default

244 kbps

for %i in (C:\Users\Use\Music\c\*.flac) do ffmpeg -i "%i" -c:a aac -aac_coder fast -q:a 1.868 -strict -2 "%i.m4a"

after tweaking i was able to do a good file

q -1

standart libvorbis

<@416586441058025472>you do tests at high bitrates. Absolutely **no one** disputes or doubts that better than OPUS for bitrate 64+ is does not exist, and is not even planned

I just noticed that at ultra-low bitrates, OPUS is the worst

12 kbps 8000 hz

it just fun

8 kbit opus is good for this

<:Opus:805856410235437068>

And, what the hell is this?

<:ReeCat:806087208678588437>

1. What is 4000=2049 2. 4004=1105 IS default 3. --cvbr for WHAT 4. wtf --speech if the SILK speech codec FORCE Stop to be used after a bitrate of 64 5. --framesize 60 is ok. but for <64 kbps

<:BanHammer:805396864639565834>

He special boi <:KekDog:884736660376535040>

I tried on https://youtu.be/ju2AB5E76d4 (starting from the CD) but it suffers quite a bit

I would have thought that the Mellotron section around 10:00-11:00 might have survived better

(seeing as Mellotron is not particularly hi-fi to begin with)

(note: the filename is 8k as in resampled to 8kHz, but it ends up being 13kbps)

20:55+ is made a mess but that was more to be expected

Well, low bitrate audio is generally intended for speech.

NOW I found a great failure of the opus codec - it can't handle stereo speech at 64 bitrate (CELP only)

What sample and arguments?

lol the Great spectral stereo artifacts

That looks like it is stereo

I thought it was some kind of sound problem that the codec does not process it, but the waves on level

on eng track is really not that noticeable but.

I don't understand - the waves are in place, the frequencies are the same, the encoding parameters are identical, why are there so many artifacts?

it's so bad that I'll have to change the codec, maybe to Vorbis or even AAC-HE

It is stereo. I don't have the original to compare to; what kind of artifacts are you hearing?

The English sounds fine. The issue is with the Russian one?

first, put your headphones, then listen on the first file, and start listening to SPEECH, you will hear it right away. all artifacts disappear as soon as you pull out one headphone

artifacts can be heard on both, but for some reason in English they are almost invisible