JPEG XL

I see.

I'll see if I can easily fix it. If I can, I'll just submit a PR to the mozjpeg guys.

That doesn't seem like it fixed it.

It didn't accept my change. 😛

I'll probably find another way to fix it.

Some comparisons on photographic sets (I didn't add JXL because it's in a different category, not storage formats) <https://old.reddit.com/r/jpegxl/comments/mepoun/modern_lossless_jpegxl_still_defeated_by_old/gtm8geq/>

The Fastest, Safest PNG Decoder in the World <:Thonk:805904896879493180> <https://nigeltao.github.io/blog/2021/fastest-safest-png-decoder.html>

<https://github.com/google/wuffs> ```Summary: Wuffs’ PNG image decoder is memory-safe but can also clock between 1.22x and 2.75x faster than libpng, the widely used open source C implementation. It’s also faster than the libspng, lodepng and stb_image C libraries as well as the most popular Go and Rust PNG libraries. High performance is achieved by SIMD-acceleration, 8-byte wide input and copies when bit-twiddling and zlib-decompressing the entire image all-at-once (into one large intermediate buffer) instead of one row at a time (into smaller, re-usable buffers). All-at-once requires more intermediate memory but allows substantially more of the image to be decoded in the zlib-decompressor’s fastest code paths.```

i liked their "puffs" name better

🤔

No JXL or AV1 :(

Wait, it's that Nigel Tao?

Man, it's been so long since I've heard of him.

He's extremely good at mathematics.

it would take a long while to write a JXL decoder in that language... also with SIMD, probably going to be very "fun"

given the surname, I'm not too surprised (jk, I don't think he's related to Terence Tao :P)

Oh you are correct.

I often mistake Nigel Tao for his brother. 😛

I didn't know they were actually related xD

both went to IMO too, so there's some genetic factors there 😛

more like same education

I doubt that's enough for IMO 😛

but maybe things were different ~30 years ago, who knows

http://gailly.net/05533051.html haha

"Making abstraction of the legalese, claim 7 says in short that you can compress an arbitrary sequence of two bits down to one bit. It took three years to the patent office to ascertain the validity of such a patent. A person with basic knowledge in mathematics and data compression can find the flaws immediately upon first reading."

Sad

http://mattmahoney.net/dc/barf.html

Sound like a very bad scam

Or a good joke

Someone actually tried to patent "circular transportation facilitation device". Any guesses what that could be?

Haha yes, it was in Australia iirc that they patented the wheel

this seems to work but there's some catch i'm not missing

obviously it's a joke but

someone did some good research for this joke

no i'm absolutely stupid i just realized

the bytes are in the filename

haha

this is pretty good

Matt Mahoney of PAQ fame

I managed to fix the issue by messing with the CMake flags.

I specifically looked at the set of conditions used, and then I found line 726, which was set to only look for libpng 1.6.

I'm revisiting my multi-codec comparison: https://discord.com/channels/794206087879852103/805176455658733570/828588867065217064

And I need your help. Which JPEG XR transform overlapping do you visually like the most?

0

1

2

2 I guess

all three are unappealing

YOU DON'T SAY <:kekw:808717074305122316>

You have to pick your poison

I mean I would honestly prefer VVC smoothing all the detail until it's an anime over that, and also vote

0 and 1 have that kinda smoothing effect

I might be wrong but 0 looks like it has the most detail

Don't blame him, blame the guy who made it default for chrome to request webp from servers that can serve it

It's annoying as hell to have a .jpg link but the server serves webp too so you download it and get a webp

why is that a probleem?

That doesn't happen anymore anyway

Chrome pretends not to know what webp is and re-requests the image when you right-click save a webp image

Which is also annoying btw, I usually want to save the image I am seeing, not a fallback jpeg...

I'm just interested in downloading the original image

Not anything derived from the original image

most web thing ever `Chrome pretends not to know what webp is`

https://twitter.com/R1CH_TL/status/1382738910091042823

Google often violates their own recommendations. I remember they worked with the IAB years ago to produce guidelines for advertising. There are many cases of them not following them along with their own web recommendations. It's always a case of "do as I say, not as I do."

almost like the people working on the blog are different from the people who make web performance recommendations 🤔

Not about who works where, it's the idea that if Google makes broad-targeted recommendations you would think that all parts of Google would follow them.

well good luck getting 100k+ employees to follow the same recommendations. what _would_ be nicer would be if they used (or developed internally) a blogging platform that would take care of this stuff automatically. convert all gifs to videos, convert images into a bunch of formats, etc etc.

Yeah, software mitigates this, so one wonders why they don't utilize it.

Good luck getting the millions of developers outside Google to follow them as well.

Realistically, it's probably that below some threshold MB is deemed good enough for already "large" media anyway.

which encoders does it use

https://deploy-preview-987--squoosh.netlify.app/editor

so new draft in squoosh github

with avif grain synthesis demo

what avif version and commit is?

can you check please i'm interested

version 0.5.4 i think

the commit

from today yesterday

when specific date

the aajsjskl

the commit is here https://github.com/GoogleChromeLabs/squoosh/tree/fca5f0860b503952655f004f00fbb60ba88fbe6e

4 hours ago

wp2 codec

ah the branch

avif is at level wp2 was 3 months ago

i used those options

I found my old avif screenshots

some are quite small

^ 493 bytes for 🙂

273 bytes, noob ! (-m -s 9 -E 3)

use vp9 28-12-2020 it's the best quality for 720p av1 is still a new technology it can reach great reduction if you use 1080p and a bit more than youtube bitrate

this is from a video server r/av1 comment by me

i don't know the settings for that video

Also <https://encode.su/threads/342-paq8px?p=68562&viewfull=1#post68562> > My GDCC entries were prototypes of ideas I had for some codecs for it, the main goal for me was to have a framework that handled detection and clustering so that with specialized codecs one could get compression ratios close to paq8px but at 2-3 MB/s on contemporary hardware. mpais is the EMMA author

so what you think jpeg xl can compress more than vp9 28-12-2020

or is only marketing

the image quality is really better of even this is pure marketing

Why are you using VP9 (the video codec) to compress still images? Or alternatively, why are you trying to use JPEG-XL to compress video?

i know

but i don't think jpeg xl can compress x3 more a file

I've had some .PNG files that JPEG-XL has been able to reduce by more than 3 times over in lossless mode, although I would agree that the majority of images are not that reducible. I would expect lossy reductions to reduce the size of files by a fairly large factor however, which JPEG-XL has been able to do quite well. Are you comparing single-frame VP9 videos to lossy JPEG-XL? I'd assume that would be the most fair comparison, although I may be wrong.

VP9 should be somewhere between lossy WebP (VP8) and AVIF, probably closer to lossy WebP (or even worse in practice, since VP9 doesn't have an encoder tuned for still images)

I see nobody testing vp9 i frame (and x264 iframe), only x265 iframe with BPG and heif, and it's a good denoiser image format 😄

🤔 <https://www.khronos.org/news/press/khronos-ktx-2-0-textures-enable-compact-visually-rich-gltf-3d-assets> > Today, The Khronos®️ Group announces the ratification of KTX™️ 2.0, adding support for Basis Universal supercompression to this container format for reliable, ubiquitous distribution of GPU textures. > Additionally, Khronos has released the KHR_texture_basisu extension enabling glTF to contain KTX 2.0 textures, resulting in universally distributable glTF assets that reduce download size and use natively supported texture formats to reduce GPU memory size and boost rendering speed on diverse devices and platforms.

<https://playground.babylonjs.com/full.html#YD2TXP#22>

<https://www.khronos.org/ktx/> https://www.khronos.org/assets/uploads/apis/2021-ktx-comparing-ktx-with-basis-universal-to-image-formats_2.jpg

GPU texture formats still need to be fixed bpp, right? (in memory, not on disk)

As far as I know, yes

I wonder if jxl groupdim might be small enough to use a subset of jxl with padded groups as a gpu texture format

Isn't decoding speed especially important for GPU textures?

I know jxl is fast but is it fast enough for being a GPU texture format?

Not in general, but a subset might be

so do most games store textures on disk in gpu formats? or do they store in some other format and convert to something the gpu can use upon loading?

since afaik gpu texture formats aren't very efficient, i wonder if they could be losslessly compressed as in jpeg → jxl transcoding

they already do that I think

ooh interesting

Yep https://github.com/BinomialLLC/basis_universal

<http://renderingpipeline.com/2012/07/texture-compression/>

https://blog.youtube/inside-youtube/new-era-video-infrastructure

https://arxiv.org/pdf/2104.10544.pdf

what is this

It is a doctoral dissertation.

AV1 on YouTube is great

But their bitrates are like 10% lower than you need to get as good an image as their avc and vp9 encodes

There's also another problem: their stream quality with AV1 is not consistent.

At times, with a bitrate only slightly lower than VP9, I get top notch quality.

At other times, I get 40% lower bitrate than VP9 and it's garbage.

AV1 still can outdo vp9 at lower bitrates but it's not magic

YouTube can maybe squeeze 10 or 20% of the size of their vp9 encodes out

But not 30 or 40% that's when it begins to be an issue

Vp9 with 580 kbps 720p looks better 28 12 2020

I've been thinking about it actually: Is it possible that the reason video quality varies so widely per AV1 encoded video is exactly because that they might be using CPU encoding for some videos and an FPGA based solution for others? It's been over a year since Google talked about having FPGA based encoding, and we know CPU based encoding, especially with more complex codecs, is quite a bit superior.

I guess They used their chip

Like, I can get AV1 to look better than VP9 at 50% of the bitrate, but it requires using more advanced encoder techniques and actually capable settings.

Techniques that YT would not want to use as it would make their audiences used to higher quality encodes <:kekw:808717074305122316>

They should be able to use the best encode settings, they usually wait until it gets a certain amount of views and if it's a certain newness

So they have the time and ofc the hardware to make a good encode

But do they care enough to spend the time on it?

We'll never get the true answer to that question sadly, since we will never know Youtube's true encoding settings.

They care enough to start using it in the first place

I heard YouTube used something like a CRF of 30 or 33

But it's probably a lot more complex

Probably extremely long

Eh, encode times aren't much of an issue. I encode AV1 daily and it's not slow if you know what to do.

No

I mean the arguments and cli

Are probably really long

True. Their encoding pipeline must be insane <:kekw:808717074305122316>

YouTube could make really good encodes considering

Even on avc

Since they have hundreds of millions of videos and giant machine learning infrastructure

If they wanted to make some system for using machine learning to best tune videos they could

https://www.youtube.com/watch?v=5ChlMMh1mJ0

watch this at the start at 360p

you see how the algorithm delete the particular you can't see

this is very intelligent

Explain

new vp9 quality

at 720p

it becomes less

this is maybe with the new chip

or some variation

but i do not think italy has yet gotten

he don't even look like himself

too filtering of the image

355 KBPS

wWTTF

AHAHAH

AHAHHA

AHAH

how can you see something you can't see?

Observing it's effects on other things you can see.

palette is evident in this

this is not worse than what i did today with jpeg xl

but sure youtube i hope the algorithm increase sometimes

but i don't care

music is music

beautiful banding at 720p vp9

level 3

What about encoding to AV1 lossless?

I use `ffmpeg -hide_banner -i input.avi -f yuv4mpegpipe -pix_fmt yuv444p uncompressed.y4m`

and then `aomenc --lossless=1 --threads=4 -o output.webm uncompressed.y4m`

And it's damn slow. Can you speed it up somehow?

The input is a lossless screen recording of an old game that uses only 4 colors. 😜

That's easy. Don't use lossless AV1 <:kekw:808717074305122316>

Oops, that's not the kind of reply I was hoping for… 🙂

AV1 lossless gives the best compression results out of all lossless formats I've seen so I'm kind of stuck to it.

Tried ffv1?

Not yet. Will try, thanks.

exhale 1.1.5 rc1

https://hydrogenaud.io/index.php?topic=118888.msg996679;topicseen#new

As I know, x264 have best lossless performance. Outperforming ffv1 and x265

H.264 lossless is fast but the compression ratio is far from best. ffv1 disillusioned me with huge output files. AV1 lossless is bloody slow but gives the best compression ratios.

If anyone is interested, I can provide my test results when I'm back to the computer.

ffv1 but is the version standardized

or the one from 4 years ago

btw as I remember, AV1 is not actually lossless in lossless mode

it's broken

it's lossless if you don't do YCbCr IIRC

does it still compress that well in that case?

also, last time I tried lossless x264, I think I might have encountered the same issue

but I could have done it wrong

I should try again one of these days

just running `ffmpeg -i riv.mkv -c:v libx264 -crf 0 riv264.mkv` gives `[Parsed_psnr_0 @ 0x563e89be0180] PSNR y:inf u:inf v:inf average:inf min:inf max:inf`

i think one needed 10bit ycbcr for 8bit rgb to not lose data or something like that

assuming your source is rbg?

most video source material is some flavor of YUV (really YCbCr) already no?

yes, it is)

it's actually quite hard to find anything rbg outside of test samples

pretty easy if you want to encode rgb avif actually losslessly though

`[Parsed_psnr_0 @ 0x559f985b3e40] PSNR y:inf u:52.872374 v:53.360745 average:57.880911 min:57.706772 max:58.177437`

It's aomenc lossless

`--lossless=1 --threads=64 --cpu-used=6`

and it weights more than x264 lossless

iirc, that wasn’t my experience with crf 0

but I don’t even remember for sure what it was that I was encoding

maybe my Prince of Persia 2 playthrough

IIRC there was issue with ffmpeg that crf 0 wasn't mapping to -qp 0, or something like that

So x264 wasn't running in lossless mode with crf 0

that might have been it, yeah

fwiw it was last year, if it was the POP2 playthrough

April 2020

I think they're going to add YCoCg or some other RCT to AVIF or AV1 to better do lossless compression

It's a bit worrying though that they can still add things like that to the spec at such a late stage while expecting interoperability.

When I started learning lossless video transcoding, I found this article from 2018: https://www.texpion.com/2018/07/av1-vs-vp9-vs-avc-h264-vs-hevc-h265-1-lossless.html

At that time, AV1 lossless wasn't lossless. But the current versions of aomenc do lossless really losslessly and the compression ratios are much better than the competitors.

So you remember it correctly, <@!258670228819410944>, but things have changed. 🙂 And it's good.

So if people want the lightest lossless videos and to grow old while waiting for the results, 🙂 they can do AV1.

Is it still good if you take encode speed into account?

I think for many lossless video use cases, encode speed is as important as decode speed (since it's usually part of workflows that are basically encode-once, decode-once)

I think av1 lossless is good for archival

Think, public library, or video archive

For workloads that require encode once, decode once, I'd think a faster but less efficient codec would be ok

Especially since you're presumably getting rid of the video after you decode it

Agreed, AV1 is a no-go in such cases.

I think AV1 is mostly useful for encode-once, decode-many-times use cases

Archival is typically more like encode-once, decode-never (i.e. you don't care much about decode speed, the file is probably stored in some very high latency storage anyway so that will negate any advantage of fast decode)

So there I think more symmetrical compression makes more sense. Also things like error resilience are probably more important (not much point in doing very strong compression if it forces you to bump up the redundancy of the storage because a single rotten bit can spoil the entire thing)

i've used FFV1 before when doing several processing steps on some raw video material

just because i didn't have enough storage for the whole thing uncompressed

it was indeed mostly encode once / decode once (or maybe a few times)

well, we certainly hope so, at least 😛

it seems likely as JXL should be getting browser support soon™️ while afaik none of those other standards were ever supported in browsers (except maaaaybe jpeg xr in ie/edge?)

Do any of them have features that JPEG-XL lacks?

Nasty patents? 🤣

jpeg xt, if i'm understanding correctly, is about adding more data to a jpeg file that jpeg xt decoders use to improve quality while the files are still compatible with jpeg decoders

I misread that as "parents". Was confused.

doesn't jxl do something similar with vardct? where it can provide a jxl with the vardct info or a worse jpeg?

no, jxl is not a directly readable jpg. a jpg decoder cant do anything with a jxl

You may be thinking of the JPEG lossless recompression feature, but that's something very different. It's not compatible with existing JPEG software; it just permits reconstructing the input .jpeg file exactly (but you still need a JPEG-XL decoder to do so).

XT is indeed backwards-compatible — but that approach doesn't really work imo, e.g. you do have "graceful degradation" in the sense that the image decodes with existing jpeg decoders, and you can add an alpha channel that a jxt decoder can understand, but that still doesn't give you alpha with the old jpeg decoder, so in practice you will just see a non-alpha image (until people upgrade their jpeg decoder to understand XT, but that just doesn't happen because "it works with the old decoder")

For less essential extensions like adding HDR data while having a tone mapped image in the jpeg, it does kind of work, but still it is hard to get adoption of the new things if old decoders also "work" (poorly, but end-users don't know that)

I don't think so. JPEG 2000 is a bit more flexible in terms of bitstream organization and reordering, but it is not clear to me if there are any use cases where it would actually make a difference.

LS and HTJ2K have a different trade-off between density and speed (encodes faster and less dense) which I suppose makes them more suitable than XL for some use cases - though it's not clear to me if jxl encoding can also be faster and worse — I suspect LS does not have an advantage over XL, while HTJ2K can probably offer better latency/throughput than XL.

So assuming jxl gets widespread support, I think it supersedes all existing JPEG codecs for most use cases, with the exceptions of: - XS and HTJ2K for professional video production (and possibly camera raw) - JPEG Pleno for non-2D images (pointcloud, lightfield, holography)

Meaning the others are basically in "maintenance mode", only relevant for legacy reasons.

Intra only, yes

For production / digital cinema, not for end-user delivery

Maybe medical too

We have <@553324745240608773> here, who will be asleep right now (US timezone) but he knows everything about (HT) J2K and can explain better than me what the use cases are.

https://youtu.be/Jvb3mUCyHH0

The proof that aomenc doesn't do lossless I made right now, it's now, not from 2018

OK, I could be wrong.

Do you have any examples?

What I do is that I take input videos which have exactly 4 colours in every frame, encode them with `-pix_fmt yuv444p` to AV1 lossless, do a snapshot of a random frame and count the colours. If the result is 4, I consider it lossless. I could also do PSNR but I'm too lazy for it. 🙂

So you wouldn't detect any color space transformations?

Ok, you shouldn't do it like that

I managed to make lossless av1

` ffmpeg -i riverbed_source.mkv -c:v libaom-av1 -cpu-used 6 -b:v 0 -aom_options lossless=1 riverbed_av1.mkv`

it's still bigger than x264 medium, even with cpu-used 0

A mjxl like a mjpeg is possible? For example teamviewer are using mjpeg and refresh only moving part of image. And stupid security cam too.

How do you mean it? Like the encoder does something that I don't expect? Or like I use some param?

If the encoder applies a non-reversible color transformation, you would incorrectly treat that as lossless.

AFAIK it doesn't.

It does YCbCr by default

which is basically the same thing as converting 8-bit RGB to 7-bit RGB with somewhat more precise G

so it loses ~2 bits per pixel, which are typically very high entropy bits (since they're the least significant ones, so they tend to behave like random noise, i.e. not compressible)

if you want true lossless, you need to either encode in RGB, or do only reversible color transforms, like YCoCg

RGB can be done in AVIF, but it has poor compression (since no color decorrelation at all happens)

YCoCg is being added, I don't know if it can be done via ffmpeg already

<@456226577798135808> Happy to discuss J2K in more detail. In summary, I would say that J2K has pretty much unmatched scalability: the same codec can handle an arbitrary number of channels, integer and floating point pixel color values, lossy and lossless coding (important for archival applications), partial codestream decoding (by pixel bits, position, resolution, etc.), low and high-latency (few lines vs entire frame). Here's a demo of J2K doing partial streaming/decoding of 16-bit lossless 4K RGB frames (20 MB+ each). http://sandflow.com/public/wow/index.html. Do not hesitate to DM me.

Oh God, JPEG XL would be soooo powerful here... Patches could act as a rudimentary form of motion compensation, the cursor being the easiest one because it almost never changes 😃 For this use case lossy Modular would probably be better than VarDCT.

I think the latency will be a problem

mjpeg with refresh of only moving part could be directly translated to recompressed jpeg frames

(but you're still going to be better off with something like h264)

MJXL would be a very nice update for those cheap ass capture cards <:kekw:808717074305122316>

Using chromium 89 and same behavior, interesting

Yes, here's what is happening.

There is an MXF file stored in an S3 bucket. The MXF file contains a sequence of lossless J2K frames. Each frame is a 4K image with 3-component pixels, and each components is a 16-bit integer.

Each frame is therefore approximately 20 Megabytes

so the bit rate at 24 fps is approx. 8 Gbps

... so it is evidently impossible to stream the video in realtime in its entirety

Each J2K frame is however organized in resolution progressive order (a 20-year old J2K feature)

It is therefore possible for the client to read the first N bytes of each frame (based on the available bandwidth) and decode whatever resolution is present in those N bytes.

So the low resolution video that you see is a low-resolution extraction of each frame

When you pause, the remaining resolution information is downloaded and you get the full lossless frame

*the key idea is that no proxy is needed to view this 4K video*

This of course works with lower resolution lossy files (in which case the video would look much better)

(the MXF parsing and J2K decoding is done in-browser)

4K lossless 48-bit files are routinely used for professional audio-visual masters/archives

When you pause in a perfect moment <:kekw:808717074305122316>

Yes, the demo uses HT, which offers an alternative to the original J2K arithmetic block coder -- HT is much faster. No change to the wavelet transform and codestream structure, however. There is an open source implementation at https://openjph.org/

The same principle would work with the original J2K arithmetic block coder, minus the increased performance/lower latency

What does HT stand for?

High-throughput

Ah.

the HT block coder just plays much better with modern highly-parallel CPU/GPU architectures

HT was published as an common standard between ITU and ISO in 2019: https://www.itu.int/rec/T-REC-T.814/en

av1 new hw chip by youtube

Regarding WebP2: I am still wondering which (planned) feature is supposed to make it especially suitable for the web, besides its name. I can see how its design choices make it _not_ suitable for some non-web use cases (e.g. limited to 10-bit, which is not enough for authoring workflows), but I don't see what features it has / will have that make it more suitable for the web than, say, jxl.

b-but polygon previews

(not serious feature, but a bit interesting one)

in general I agree though. right now I'm not seeing it either

Yes the triangular preview thing is fun but it's basically a builtin blurhash-type placeholder of a specific kind, in principle it could be added to most formats as a small 'metadata' chunk that goes early in the bitstream, if it's considered useful. I personally think a preview needs to be a bit closer to the final image to be useful, though.

I think avif people were considering adding something of that sort too (chunk for preview, I don't think it was with polygons though). in general previews are inferior to progressive decoding imo, as they take up additional bandwidth and information gets discarded once image gets fully loaded. only really small ones like in webp2 makes sense to me

As far as I understood it mostly priority for low bpp, like previews in YouTube and other applications, UI elements, with faster encoding speed than AVIF, minimal headers, incremental decoding and higher efficiency than lossless WebP with comparable speed The current implementation is slow, but it's not optimized yet

https://github.com/AOMediaCodec/av1-avif/issues/102 ah this got closed

closed with reference to https://github.com/AOMediaCodec/libavif/issues/605 ..?

so it seems they gonna do it heh

Yes, I see the potential improvements of webp2 compared to avif: smaller headers, better lossless, faster encode, maybe faster decode. But I think jxl already has those things, or am I missing something?

Maybe the focus on low bpp

I personally dislike webp's and webp2's "web" limitations

For medium and high bpp I do not see any particular advantage, but I think at low WebP2 may be better

is it going to support progressive decoding, though?

No

because without that I can't see how it's better at all

Incremental but not progressive

incremental? you mean that poly preview thing, or something else?

No just top down

oh

Sequential I usually call it

But they call it incremental

well, that's at least better than avif, I think

Avif could probably also do that, it's just that in a video decoder api you don't tend to bother with the hooks for that

I don't really see a large use case for low bpp but not progressive - usually low bpp is good when network speed is an issue, but that's also when progressive is most useful

From the server pov to save bandwidth/storage cost it still makes sense, but from the end-user pov not so much imo

if image is small enough, it wouldn't need much of progression to load on medium-high speed networks, but would still save bandwidth for server side

ah yeah you just said the same

The triangular preview or LQIP can be about equal progressivity for the perception of faster loading (but if the network speed is not extremely slow) Like 2-3 steps of progression, but not much more

It can help to reduce flashing

But that's only when it all loads within a second or so - if it's slower, then you're not really going to get perceived faster loading since those previews are still quite far from a 'usable' image

(e.g. if it contains text you won't be able to read it, if it contains faces you won't be able to recognize them)

format not being finalized yet allows them to add something better, maybe. not sure at what stage they're at, and if they have plans for anything else

As far as I understood from Pascal Massimino's messages, no changes are planned and these are intentional limitations, because such features are not needed in practical use Like their benefits are not proven by any practical research (for web use)

goal of being on par with avif on decoding speed also sounds kinda ehhh as avif is pretty slow compared to others

btw, how good is wp2 lossless?

should look into your benchmarks, maybe you had column for that

jxl winning that

Is a little better then webp

Yes, lossless WebP2 is an improved WebP, it is also consistently more efficient, and considering that the encoding speed will remain almost the same (after optimizations), this is a good result

It is a good and useful result indeed, but it would also be good to work on making lossless jxl better and faster. The use cases for lossless WebP2 are limited to the web (small non-photo images) because with the size and bit depth limitations it will not be suitable for image authoring.

It already does imo, but the encoder could be optimized more to get better speed/density trade-offs.

Basically the current speed 3 is a fixed MA tree that we know works well for photos, so tree learning is skipped completely, which makes it quite fast.

We could do more fixed trees like that for different kinds of images and heuristically choose one of them, to get fast encode (even slightly faster than s3 in some cases) that is still as good as anything else.

At the slower speed end there is room for improvements in the tree learning algorithm and more exhaustive / less greedy search could lead to better densities than what we get now.

This explains why cjxl currently doesn't beat the size of optimized 2bpp PNG. Looking forward to the bright future. 🙂

I remember a funny naming of PNG's non-interlaced: "straight-laced". Which normally means something else: https://en.wiktionary.org/wiki/straight-laced 🙂

The antonym of inter- should be extra- or intra- I'd say :)

extralaced, hm

interlacing is a confusing word

for still images interlaced is a kind of progressive

while for video, interlaced is the exact opposite of progressive

progressive is a confusing word too

maybe we should start calling sequential/incremental/top-down/non-progressive/non-interlaced/scanline-order images **conservative**? 😜

This kind of confusion is what happens with natural languages all the time. Let's switch e.g. to Loglan: https://en.wikipedia.org/wiki/Loglan 😄

Let's not be so conservative. 😉

in JPEG they usually call progressive "Scalable", which is also quite a confusing word

there's scalable vector graphics, there's parallelization which is also a kind of 'scalable' (with the number of available cores), there's scalability in the sense of "can be used at large scale", i.e. the computational complexity allows deploying it for use cases like facebook, twitter, google photos, etc.

but then there's also 'resolution-scalable' and 'quality-scalable' which basically mean progressive

https://github.com/fraunhoferhhi/vvenc/issues/59

it's amazing how obligatory chroma subsampling is still a thing

even in next-gen projects

eliminating non-visible chroma details is fine, but just removing 75% of the chroma data as a preprocessing step before even starting compression is quite a blunt way to do it

You can do it in DCT domain anyway by simply dumb-discarding 3/4 highest coefficients

But you've been mentioning it enough times so I'll not repeat that in order not to go crazy...

That is actually quite funny in that regard.

Most projects and devs don't seem to care much about color information for some reason <:Thonk:805904896879493180>

still too many Y-only metrics are being used to measure success

Oh, found it! https://discord.com/channels/794206087879852103/794206170445119489/807523533705052170

iirc, HandBrake’s pipeline is still 8-bit 4:2:0 only

In February of this year, 10-bit was added for software encoders which is nice at least.

oh! great news, thanks

not yet in an official release, right?

I'm not sure, as that depends on when stable releases are done. Nightly does have it though.

In regards to color, one of the things I want to get in the AV2 spec(since it is currently being drafted) is native XYB color space support in the encoder pipeline.

And not being *so goddamn slow*

Moore law is slowing down

And IMHO I think that basing AV1 on VP10 instead of Daala was wrong

Daala was quite good

Of course, that does require I write a document discussing the implementation as well as provide some proof, so when I get some purely free time, it should be doable.

wasn’t Daala primarily for very low bitrates?

It did pretty well at 16 KiB <:Thonk:805904896879493180> But the best thing is that despite HIGHEST complexity setting... ```real 0m1.168s user 0m1.152s sys 0m0.001s``` Good luck with AVIF on `-cpu-used 0` <:kekw:808717074305122316>

JPEG XL at the similar filesize for comparison

Guys at Xiph definitely knew how to optimize things...

can you add xpnsr

in avif

what is avif progressive

avif don't support progressive

im trying to figure it out too

quantizer scaling seems more efficient

i can see details if i focus more

on the third image

oh. alright

<@!260412131034267649> thank you)

add xpnsr

idrk where to put this but does anyone know how to use `butteraugli`'s command line tool? by that i mean, which of `image1` and `image2` is the reference image? I've ran the tool two times, just reversing the order of the images and got different results: ``` ❯ butteraugli prof-reconv.jpg prof.png 0.386337 ❯ butteraugli prof.png prof-reconv.jpg 0.390707 ``` The `reconv` file is the one converted via JPEG quality 100 from the png file. Which distance is more accurate? Additionally, is the `butteraugli` project even being updated anymore? The GitHub repo had its last commit a year ago.

When compiling JXL, you can use ` -DJPEGXL_ENABLE_PLUGINS=ON -DJPEGXL_ENABLE_GIMP_SAVING=1 -DJPEGXL_ENABLE_DEVTOOLS=ON` to activate a bunch of options which activate the plugins as well as some of the tools like butteraugli_main(JXL one) which is better and more up to date.

the command-line tool expects the reference image first

yes but ewout don't compile butteraugli

and yes, as BlueSwordM points out, the most up-to-date Butteraugli is the one in JPEG XL

Great, thank you for the info! Appreciate it.

butteraugli 2021-03-16 13:24 butteraugli_main.exe 3.91 MB

wait vvc reference encoder is incapable of lossless OR anything other than 420 chroma subsampling?

> The Fraunhofer Versatile Video Encoder (VVenC) is a fast and efficient "real-world" VVC encoder implementation

can it handle more than 8 bit either? <:kekw:808717074305122316>

Currently, no

seems a bit rushed to me

to push it out with just the most basic features for actually encoding any video

i guess maybe those aren't their priorities

those being 422 and 444 chroma subsampling, lossless, and 10 bit

Yes.

It accepts 10-bit as input, but I don't know how to set the bit depth of the output format (maybe it will be the same as the input or always 8/10-bit 🤔 , can not remember which encoder does what)

You need to set: `--internal-bitdepth XX(8/10)`. The default is 10-bit.

pardon if this is some famous test image, but do you have the original image for comparison?

It's the one from Xiph, the makers of Daala codec.

looks like it has a lot of blur background and i think av1 excels at encoding that

We'll talk about it when AV1 reaches Daala's speeds <:kekw:808717074305122316> Quick reminder: ```real 0m1.168s user 0m1.152s sys 0m0.001s```

Here's the absolute best I was able to do with avifenc using aomenc-av1.

AV1 is in part designed by Daala people.

I know, but the main principles ("core") was based on VP10, the never released internal upgrade of VP9. https://discord.com/channels/794206087879852103/805176455658733570/837703603958579261

I feel like there were lots of VP10 sprinkled a bit with some novelties from Daala and Thor.

I see. I'm not familiar with the details.

I just used to play board games with some of them 🙂

So, ziemek, what do you thank of my best effort attempt at the image? `avifenc -j 2 -d 10 --min 39 --max 44 -s 2 -a aq-mode=1 -a enable-chroma-deltaq=1 -a enable-dnl-denoising=0 -a denoise-noise-level=10 -a tune=ssim input.pnf output.avif`

Yep, but some very costly things from Daala were rejected in AV1 (although they may have found a more effective replacement)

But you know that the target is 16 KiB (16,384 bytes)? 😜

Indeed.

Not lying 😛

Damn, quite good...

> looks like it has a lot of blur background and i think av1 excels at encoding that I wish AV1 wasn't blurring *everything* instead of just the background <:kekw:808717074305122316>

That blur is soooo VP9-ey... The VPx codec line is quite blurry compared to x264 and unfortunately we can see that AV1 was based *mostly* on VP10.

The encoder matters much more than the standard.

It just so happens that publicly available VPx encoders are crappy 😒

I wonder how much of x264 could be brought over to an avif encoder

(disclaimer: I know very, extremely little about how either of them works)

To be fair, libvpx-vp9 has improved a lot, especially recently.

VP8 is still bad though. Only use it when your alternative choice is h.262(MPEG-2) <:kekw:808717074305122316>

Does libvpx-vp9 have psy tuning like x264?

And even if it has, why is EVE so much better? DAMN

I think eve-av1/vp9 has many ideas from x264 (and not the blurry psycho-visual tuning), since Ronald Bultje also worked on x264

But it's hard to get an encoder to compare to the average person

EVE-VP9

https://images.squarespace-cdn.com/content/v1/582b36daf7e0abc54f0695c2/1568057791099-V4HFNRU3N3EMWF5TQAH4/ke17ZwdGBToddI8pDm48kNvT88LknE-K9M4pGNO0Iqd7gQa3H78H3Y0txjaiv_0fDoOvxcdMmMKkDsyUqMSsMWxHk725yiiHCCLfrh8O1z5QPOohDIaIeljMHgDF5CVlOqpeNLcJ80NK65_fV7S1UbeDbaZv1s3QfpIA4TYnL5Qao8BosUKjCVjCf8TKewJIH3bqxw7fF48mhrq5Ulr0Hg/image-asset.png?format=1500w

libvpx-vp9

https://images.squarespace-cdn.com/content/v1/582b36daf7e0abc54f0695c2/1568057821508-H60T56J0AXY3QOUT9Q3Q/ke17ZwdGBToddI8pDm48kNvT88LknE-K9M4pGNO0Iqd7gQa3H78H3Y0txjaiv_0fDoOvxcdMmMKkDsyUqMSsMWxHk725yiiHCCLfrh8O1z5QPOohDIaIeljMHgDF5CVlOqpeNLcJ80NK65_fV7S1UbeDbaZv1s3QfpIA4TYnL5Qao8BosUKjCVjCf8TKewJIH3bqxw7fF48mhrq5Ulr0Hg/image-asset.png?format=1500w

It's so blurry that even x264 beats it lmao

https://images.squarespace-cdn.com/content/v1/582b36daf7e0abc54f0695c2/1568058225591-VPKQGT5K20Z6U922N4VL/ke17ZwdGBToddI8pDm48kNvT88LknE-K9M4pGNO0Iqd7gQa3H78H3Y0txjaiv_0fDoOvxcdMmMKkDsyUqMSsMWxHk725yiiHCCLfrh8O1z5QPOohDIaIeljMHgDF5CVlOqpeNLcJ80NK65_fV7S1UbeDbaZv1s3QfpIA4TYnL5Qao8BosUKjCVjCf8TKewJIH3bqxw7fF48mhrq5Ulr0Hg/x264-282.png?format=1500w

Man, if only it was easier to create still images with libvpx-vp9 :/

With avifenc, it is so easy.

To be fair, we don't know what settings they used/what version they used.

Wait is EVE av1 actually superior to libaom?

Well, is it more efficient and/or better looking at the same rate?

i only see old 2016 info about eve vp9. I'm not sure it's best than libvpx 2021 :D

i'm always searching big vmaf benchmark about all vp9 av1 and x264 8bit 10bits to see the actuel level of encoders.

If it wasnt better at least for lower bitrates then Netflix wouldn't be using it.

No worries, one is coming soon™️

<@!111445179587624960>

wp2 palette effort 2 how to do

You have to delete your posts from coverage first. Otherwise he won't help.

I don't know the option to force palette, maybe it happens automatically at some point

lossy palette wp2

does it exist

effort 2

Lossy palette is generally left to tools like pngquant

how to do

which quality set

i have wp2 downloaded from jamaika builds

doom9 builds

Perhaps to some extent it is used for 96-99 quality

cwp2.exe -mt 8 -progress -q 100 -z 6 -lossless 1.png -o 1.wp2

what z i should set

-q 94,6 -X 22.4 -Y 38 -I 0.68 -s 3 -m --palette --effort 2 -q 78,079 -s 5 -epf=1 --noise=0 --dots=1 --gaborish=0 --patches=0

i want to do that do other image

I don't know about wp2, but in jxl we don't have a real lossy palette yet - there's lossless palette (if the image has few enough colors, the encoder will make a palette for it), and we do have something that uses delta palette in a lossy way with the default (empty) palette, but not something that does something like pngquant (find the most important colors and reduce the number of colors to make palette possible)