JPEG XL

It's true, it's best not to use, for example, SVT-AV1 at speeds higher than 7-8. If possible, it's better to use vp9-hevc at the same encoding speeds if we're talking about fast encoding. But if the choice is between AV1 and AVC, there's no reason to use AVC for 1080p.

I can't share a link to a video that hasn't been uploaded

This is only true if you only have a choice between AV1 and AVC (svt-av1 and x264)

HEVC and VP9 can be better than x264 and AV1 at the same time when it comes to encoding time, decoding time, and compatibility.

just open a port on your PC

file:///C:/Users/Admin/Downloads/Shrek.mp4

hopefully svtav1 will get better performance at the higher speeds, but I'm not holding hope, we've pretty good tho

https://tenor.com/view/shrek-islr-movie-flash-gif-17838423

ok

NO

EVERY compression improvement needs more computation

If you limit computation to same, they become same compression

i never believe metrics on an ever evolving codec, especially when they don't state the versions used

ok

hi10 is the only thing anyone could ever need for lossy video

If you mean for videos, maybe? But in general no, that's absolutely nonsense. More efficient techniques are inevitable

hi10?

10 bit high profile AVC (preferably encoded with x264)

No? Some compression formats are just more efficient with their computation than others Like 80% of compression formats offer different levels of computation time anyways

I made this fact real <:BlobYay:806132268186861619>

To me av1 is Windows and autistic thing

convert from yuv420p to yuv420p10le has sense?

tldr: 10-bit is always the correct choice xD

if "higher cycle overhead and memory bandwidth" are a legit concern use tiles, fast-decode, progressive, whatever. 10-bit solves way more than the drawbacks of lowering decode complexity

Yes, even with 8 bit input, using video codecs in 8 bit mode results in a lot of rounding errors which reduce quality. Using 10 bit improves quality even at the same bitrate.

magic

No

🥱

<:AV1:805851461774475316> <:AV1:805851461774475316> <:AV1:805851461774475316> <:AV1:805851461774475316> <:AV1:805851461774475316> <:AV1:805851461774475316> <:AV1:805851461774475316> <:AV1:805851461774475316>

<:H264_AVC:805854162079842314> <:Hypers:808826266060193874>

Never

Blocking shit

AV1 new standard

Fully free

What

Why you delete

I feel tired that new codec have no substantial new thing

H264 is the turning point

Av1 have

Much math

There is (at least) one important path that is still to be explored. Using gradient search to find textures with large DCTs, but having them alpha blended into smaller DCTs that will hold the geometric detail (which would otherwise ring in the large DCTs). Think of having a 8x8/8x16 optional alpha blended layer on top of 256x256 DCTs. The 256x256 can create beautiful textures with relatively few parameters, but rings -- the smaller DCTs can take the responsibility to get those parts described.

Could it be done using the coding tools in JXL? Though it may require encoding in 2 layers

Yeah some variation of that can be done

Check out dsv2 ;)

No arithmetic coding? <:YEP:808828808127971399>

Of course not <:KekDog:805390049033191445> it is very simple in general

the best part of JPEG 2000 is entropy coding: arrange wavelet coefficient to bit-plane, coefficient prediction as context model for binary arithmetic coding You miss this

Yes that is certainly the most interesting part but it is not only slow but complicated as well

Not saying dsv is even comparable to j2k im just saying it’s also a wavelet codec haha

anyone have a clue what the `hdgm` icc tag contains? seems to be related to gain maps on apple hdr screenshots but i can't find anything on it is it part of some new standard or fully proprietary?

svt-av1 3.1.0 — Overall, it's excellent; a lot of the things I didn't like a year ago have been fixed. So my svt-av1_fork has almost no purpose left, except for the gameplay compress, which is the only thing I see as an mine advantage for now (I hope in a year this will be gone)

I looked in the source code, and the "block overlap" (wm_level) setting is still there at "preset 1". So if you're encoding something for a very long time, I recommend using preset 2 as maximum, since with preset 1 and lower, the DEcoding speed will be approximately 2-3 times slower, which can be critical for smartphones even with hardware support for AV1 <:AV1:805851461774475316>

anyone else think jpegli decode is a bit blurry? I guessed it would have less filtering than djxl and be more accurate for high-quality jpeg, but seems not

I find jpegli disgusting <:PepeOK:805388754545934396>

I trust you

Here

It's funny, I've never save images smart now. Any content is already a saved image. If I make edits to it, it's most likely a PNG that will then be recompressed to JPEG or WebP on one of the sites. And if we're talking about places where the uploaded files are the original files, why use JPEG at all? If you need compression, there's WebP, but if you don't, who cares if your PNG is 100 KB or 900 KB?

I am only looking at decode in this case

Sometimes I save a huge image, and the only codec that decodes the fastest is Baseline JPEG. I use a very specific key that perfectly save all the lines and details, with very few artifacts. mozjpeg-v4.1.1-win-x64\shared\Release\cjpeg.exe -baseline -notrellis -sample 2x2 -quality 70 -tune-psnr -quant-table 1 input.png > output.jpg

More quality mozjpeg-v4.1.1-win-x64\shared\Release\cjpeg.exe -baseline -notrellis -sample 1x1 -quality 90 -tune-psnr -quant-table 1 IN.png > OUT.jpg

In 2025, this is the fastest way to decode an image, with near-perfect quality. It can't get any faster (for lossy)

I have the JPEGs from an old camera. Using `cjxl in.jpg - | djxl - out.png` gives the most accurate decode as far as I can see.

So, transcode to JXL is loseless

Yes, it is just a path to libjxl's decoder.

Then I didn't quite understand what jpegli had to do with it if it was just a jpeg encoder.

I compared djpegli on the same JPEG source, and the output was too blurry to my eyes.

Well, it seems to me that you wanted some kind of magic. Maybe use the SCUNET-GAN neural

Maybe it will give me an image better than the camera sensor could capture. =P

I also agree, jpegli's decode is too blurry for me

Yeah, jpegli decoding gets softened slightly by something in the pipeline

jpegli? what is it? we have jpegxl

Classic JPEG with the knowledge of JPEG XL

you mean it don't remove compatability with default jpeg?

It is default JPEG, but with a fancy encoder

a new JPG encoder+decoder thats more efficient than mozjpeg, created by one of the jpegxl authors and a main contributor to libjxl. fully compliant with libjpeg6.2 (the JPG profile level that became the defacto standard since 2000) and optionally libjpeg8.0 designed to seamlessly replace your current JPG library by just swapping dlls

alright cool, but it is still jpeg

its still important for JXL. if you planned to keep using JPG for however long you need, you get nicer looking JPGs that you can eventually convert to reversible jxls that will then look better than if you initially generated them using a low quality or ancient JPG library

Tip: a lot of -li projects related to compression are done by the same team

Guetzli also encodes like Jpegli but is much slower

named by Jyrkli

meaning small Jyrki

much slower, and from my tests, not even beaten jpegli

Well that's because it was jpegli's precursor

https://discord.com/channels/794206087879852103/794206087879852107/1329992045116264519

I can't see this message smh asks me to join the vocal channel, but cannot see a text channel in it...

I managed to see the message from Discord search

For other people

But what about it?

I was searching here a comparison between pingo and ECT

Ahh

from what I saw, read and tested seems like pingo is faster, and is far better with alpha ECT on the other hand beats pingo with appropriate settings when there's no alpha, but can be quite slow

I just hate that pingo's default is lossy compression [⠀](https://cdn.discordapp.com/emojis/939666933119324222.webp?size=48&name=whatisthis%7E1)

Does anyone know if there are tools that can estimate what level of quality loss a JPEG has from the unknown original?

check quantization step?

Alright, apparently ImageMagick can estimate a libjpeg quality number from the quantization tables. It says 92, so I'm reasonably happy.

And there is no way around conversion to 8bpc, last I saw.

https://youtu.be/yT6cKgZI8n0?si=Ucb3nsOed7hmltwd

av2? huh? even av1 is still not so popular, they already do av2?

popularity is forced. they couldve called the codec 'youtflix video' since its mostly used for web services to serve their own apps/browsers av1 videos, as bitrate-starved as possible

hevc is still king for longterm support and non-low bitrates make it undesirable to adopt aom's [fad of current year], especially for tv broadcasts, disc media and good cameras

how is it not popular?

I see it everywhere

I guess AV2 will be the royalty-free counterpart to MPEG's VVC, trying to keep up in terms of compression performance with the patent-encumbered codecs...

popularity isnt a reason for a new standard to not be developed, and while you might think av1 isnt that popular there are likely many services which provide it which we dont know about

In video codecs this pace of new codecs is quite normal — which is also why it's a bad idea imo to turn video codecs into image formats, since they tend to be outdated before they're really adopted

in the case of AVIF, IQ Tune has significantly improved its quality so its now a competitive format

hard to say, I probably won't be adopting av2 in any of my stuff unless they make it api compatible with aomenc and dav1d lol

removed video but i can still watch it on the android app, though likes and comments etc. don't load

weird

i can also watch it in the tor browser now

i saved the slides if you want those

if it's a public link sure, not sure about reuploading

no i screenshotted the slides

oh

well for now it seems to play fine in tor

i would like to see h264xl (h264, just better) jpegxl (jpeg, just better)

i give you a permission to patent this as an advertising slogan

so H.265? <:KekDog:805390049033191445>

I actually assumed MPEG and JPEG were part of the same consortium or similar in other ways because the acronyms are similar, but I have no idea if that's true now that I think about it

av1 is vp9xl

Let's invent a version of h264 that uses fp32 for maximum precision.

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

this one seems to work

Well, what does it mean for a format to be *outdated*, really? It'll still be several years before AV2 can even become mainstream (due to a need for production-grade encoders and decoders), let alone have companies use AV2 in their products. Also, we aren't even sure if there will be a still image format for AV2, so AVIF will remain a valid option in the future as it is right now.

Also, the fast-release cadence for traditional codecs is over. There's a 7 year difference between AV1 and AV2, and I bet it's not going to get any faster.

I mean, for images it should last a decade or two at least IMO

ok, but which difference between av1/2?

a lot of technical differences, what's most relevant is that it has 30% bitrate savings over av1, better deblocking filter, improved hardware decoder which should lead to more adoption, has features meant for multi streams and vr/ar

and also because image formats are mostly intended for sw decoding, so as soon as support is available in chromium, it's already very widely supported while for video formats hw support is basically mandatory for mass adoption

and compatability with av1 decoders?

no

swsec perf and efficency is super important on low end hardware too

but AV1 isn't going away any time though, and I reiterate that we don't know whether there's any interest to create a still image format from AV2, so its "shelf life" is potentially even longer than 7 years

I have no interest in av2 for my stuff anyways lel

yeah, but still not the same as for video

At what quality was the 30% number measured?

except that as soon as youtube added avif for images and previews on youtube, on one of my old systems it became almost unusable if I opened more than one tab, because it consumes a lot of memory and cpu <:kekw:808717074305122316> although before it was fine even for like 20-30 tabs

this is why I think avif is a fail

though perhaps it's not just avif, but other UI updates and heavier scripts and other stuff and it's quite an old system, but still pretty noticeable how youtube has become much slower even though before it was perfectly fine on the same config

this might be worth a watch: https://www.youtube.com/watch?v=f0ivgL8vu9w

but they measured PSNR, SSIM and VMAF against the AOM CTC test set

efficiency improvements range from 27 to 32%

Google also performed a subjective evaluation, and MOS improvement was larger (up to 38%)

I think this means it would be about 23% better on still images?

that'd be for all-intra video

there's another slide for still images

intra frames still predict from each other? if so i don't really understand why there's a distinction between the types

Tuning for still images is generally different

i guess this is the still image

not insanely huge gain but still significant

on low end phones, a stream of avif is way harder to to decode then a stream of jxl files on battery life, this can easily be testing with a gallery app, manga app, or a browser

well, if I were to really quantify it, I would say that avif is about as hard to decode as some nasty modular jxl files

JPEG is WG1 of SC29, MPEG is basically all the other working groups of SC29. So both are part of the same subcommittee (SC29) of JTC1 of ISO and IEC. Occassionally there are collocated JPEG+MPEG meetings, i.e. both have meetings in the same venue. But usually the meetings are separate. JPEG is a way smaller committee than MPEG, by about an order of magnitude in terms of number of people, so while JPEG often meets in relatively small venues like universities or research institutes, MPEG always requires a big conference center.

What I mean by a format being outdated is not really that a newer one exists with better compression (this can happen quite easily), but it's more about ecosystem and format features. E.g. I consider lossy WebP outdated not just because VP8 was succeeded by VP9, VP10/AV1, and now AV2, but mostly because it is limited to tv-range 8-bit yuv (not enough precision for current display technology) and has image dimension limitations that are real limitations for current use cases. Video codecs tend to have profiles and levels with relatively strict limitations on precision and dimensions, limitations that are mostly guided by the needs of the present but cannot really afford to consider the potential needs of the future because there's a need to keep hardware implementations commercially feasible. E.g. for video, even for production workflows, typically 12-bit precision would be considered sufficient, so video codecs generally won't support more than that (or they do, but only in some high profile that nobody actually implements). But for still images, even in just "prosumer" use cases, having more precision available (during production) is desirable.

I don't trust those metrics at all, and aggregation using BD-rate is problematic too imo. I get the desire to use objective metrics (it's convenient to get some numbers, way faster and cheaper than doing subjective experiments) but I think video codec devs and especially AOM have been relying on just objective metrics way too much. It's the same in MPEG where they create these PSNR monsters that beat anything else on PSNR but it all looks like a disgusting smooth plastic mess.

5 FILTERS, FEEL IT <:FeelsAmazingMan:808826295768449054>

I wouldn't necessarily trust YUV PSNR or VMAF-Y to say anything sensible at all on image (and I am going to bet most of those gains are in the very low bitrate area)

PSNR is a reasonable metric for the high bitrate region (say, PSNR>45), where fidelity and per-pixel numerical accuracy are more or less the same things. But at low bitrates, there is very little correlation between PSNR and actual image quality.

As for VMAF, it's not a fidelity metric but an appeal estimator, which makes it basically unsuitable to use for codec evaluation/development since it is very easy to cheat it: just sharpen the image or stretch the contrast a bit (either as preprocessing or implicitly by making different choices in the encoder) and you can get huge improvements according to VMAF.

There's certainly improvements that have me impressed, but a lot that causes me concern too. At this point showing PSNR is a sign you don't know what you're doing, or want to trick results into looking good. The fact HW decoders were the only ones mentioned then entire presentation doesn't give me high hopes for any legacy systems, seeing as I already struggle with some AV1 streams on my desktop yet alone my phone. All test conditions were 4:2:0, so any high quality or synthetic content is likely to be quite poor

undershot their target then <https://youtu.be/bCwjTVJ3F3w?t=1064>

I agree with what you said, but the presenters also showed a preliminary subjective test result MOS section, and the codec performs even better than what PSNR/SSIM/VMAF report, so there was some care to not over-optimize on the chosen metrics

we do need a third-party test though

are there any details on how the subjective test was done? besides "conducted internally in Google" and using an 11-point scale DCR

and to what AV1 encoder are they comparing?

I guess we're thinking of different meanings of outdated. But I get what you mean -- AVIF's forte will never be 16+ bit or gigapixel images.

my educated guess is that they're using the latest version of AV1 libaom

yeah but the difference between default and -a tune=iq is maybe as large as that difference between av1 and av2 they're showing

or (sometimes) the difference between default SVT-AV1 and SVT-AV1-HDR 😉

I'm wondering how amenable to psychovisual tuning the new coding tools in AV2 are

I think the comparisons might be mostly true, and it's basically comparing a reference encoder without psy improvements (though more mature for libaom-av1 over the years since release) against a reference encoder for av2 except that it's usually primarily streaming bitrates and focus, because that's the most interesting for the majority of online platforms and google, but it can be quite low bitrates and quality like for personal use

38% vs 40%, close enough

especially because the encoder hasn't specifically been optimized for subjective quality anyway

What can you say about highest quality preset of av1_nvenc (nvidia)?

tune uhq ≈ svt-av1 preset 6

mainline svt, community forks are better

oh wow! this is insanely good for an hardware encoder

*just realizes that she got an nvidia card too so she can use that as well*

What are thoughts on Jpeg XS? Obviously goals are different, but is it good at what it does?

if you could provide some testing to corroborate this, and even compare it to -hdr that would be neat

true... I got both amd with my iGPU and nvidia at the same time

it is super convenient

also, vship runs like a charm

I don't mean anything by it, but Exorcist does tend to copy paste things from ChatGPT a lot, so it might not be based on anything

very true

AI users are a danger now...

I think exorcist is referencing Rigaya, which shows RTX 40 AV1 being close to SVT 8bit P6 in certain scenarios

https://rigaya.github.io/vq_results/

Huh, interesting, I didn't know about that site

https://halide.cx/blog/julio-barba-interview/ > I'm very excited about features like user-defined Quantization Matrices (QMs). This unlocks some powerful applications, most notably the ability to convert JPEG images into the AV2 format without the additional quality loss that normally happens when you transcode between formats. On top of that, you can apply deblocking filters to these converted images to smooth out artifacts and improve their perceived quality even more. > > AV2 also uses higher precision math for standard 8-bit content. This helps prevent "banding" — those ugly, visible steps in what should be a smooth color gradient — which can be caused by rounding errors during compression. sorry to necro, but I think this stuff is exciting about AV2

more internal precision at 8-bit is indeed a good idea for av2, the precision in av1 is too low to avoid banding in some cases when doing 8-bit sRGB at 400 nits

I wonder if lossless jpeg recompression will indeed be possible. Just explicit quant matrices is not quite enough, there's a bunch of details that also need to be made identical...

its been 7 years not 5. there was 4 years between vp9 and av1 lol.

oh didnt realize i nerco that far back,

I think if the efficiency goals had been achieved earlier, av2 would have been released earlier as well with the same time gap between generations as in the previous ones but it seems that now, with each generation, it is much more difficult (especially for a royalty-free video format, which is still quite limited in terms of the algorithms and methods that can be used, it's a minefield for patents and also less companies are share good and strong patents and research, even among aom members) also, hardware adoption for av1 has been much slower, even now, after so many years, it is much less than 50% (and hardware is also required for drm, without drm most companies will not even sell licenses for content) for av2, adoption will probably be better and faster, and then there will probably be an era of ai video formats (patents also work differently for ai models than for traditional codecs), although I also don't know how much ai codecs will be relevant and good, efficiency has not yet been proven in real use

I dont know if it will be faster, devs already invested into testing and making sure av1 is good and well implemented. Unless av2 is practically drop in, I don't see myself even bothering with it

ill wait for AV3

but av3 can be an ai format <:kekw:808717074305122316>

[dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&name=dogelol)

considering that all the money in the world is being invested in ai and models for any purposes are developing quite rapidly, not even every year, but every week and if we assume that the time for the next generation is also about 5-8 years, then for ai it's a enormous timeframe if ai bubble does not collapse by that time <:kekw:808717074305122316>

<@297955493698076672> r u able to share more on this?

all I know right now is that lossless jpeg recompression isn't possible because are the DCT basis functions in AV2 are slightly different from JPEG

so if JPEG -> AV2 recompression does happen, it'd be one-way only

with an option to leverage AV2's deblocking and restoration filters

Gotcha, and it’d be near-lossless?

it should be, from the prototypes I've seen

:0

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

is `zli` a nod?

I wonder how useful it could be for FASTQ data

https://arxiv.org/pdf/2510.03203 > This then begs the question: why aren’t application-specific compressors more common? raises* the question

no VP9 for whatever reason

In 2025, SVT-AV1 was finally finalized to the point that, two years later, I can use not `-svtav1-params lookahead=120:tune=1:scm=1:irefresh-type=2:enable-cdef=1:enable-dlf=0:enable-mfmv=1:enable-qm=0:enable-restoration=0:enable-tf=0: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` but just use `-svtav1-params "enable-variance-boost=1:variance-octile=1:variance-boost-strength=2"` Although I still have complaints about enable-tf=1, which can do bad things on a smooth 60 fps picture, I think, in general, you can turn a blind eye if you don’t do "source" encoding <:AV1:805851461774475316>

https://docs.google.com/document/d/1SH5Pm1nRj9Qci9fBYVyE-5asj-GffL5evJa7OEZv3eY/ https://bugzilla.mozilla.org/show_bug.cgi?id=1991746 https://bugzilla.mozilla.org/show_bug.cgi?id=1991747 https://bugzilla.mozilla.org/show_bug.cgi?id=1991748

I'm genuinely upset at this. why is Firefox **intentionally** supporting MKV incorrectly

one of the main points of MKV is that you can put anything inside of it yet Firefox is restricting it to only codecs that exist within other media containers instead of the full set of codecs actually supported by the browser

when I was reading the discussions Mozilla where having about MKV support in Firefox a while back I had felt like the way they where talking about it was suspicious and weird. I guess I was right!

which codecs should they be supporting?

all of the ones supported by the rest of the browser? that's how Chromium does it which makes sense

minus images

one of the most popular pieces of recording software that exists exposes FLAC and PCM as simple options to select from a dropdown when recording to MKV (the default output container). Firefox supports both FLAC and WAV but explicitly decided to not support them within MKV

Chromium doesn't have this as a problem because they did the logical option of just exposing all of their video and audio codecs to MKV

someone should throw this at that web interop thing

to be fair, it's not like they are actually going out of their way to not support it, just that they haven't bothered to put the effort into supporting it, that being said, the fact that it's not just a - { aac, opus ...} + {aac, opus, flac ...} says more about the code organization of firefox then anything else

Interestingly, Google created WebM so they wouldn't have to add MKV, and everyone was happy with it.

Firefox will add something only when Google pay money to Mozilla

So they added things related to AI

webm only supporting free formats is immensely important for being "able to support <format>"

I've been studying compression for about eight years now, I think. But only now have I learned about Zopfli, which compresses data into pure Deflate, but much better. I'm really surprised to learn about this, because when encoding APNG, I wondered how Zopfli, from 2013, could have been added to a format from 2004. Well, it turns out that's exactly it. It simply compressed my test animation better than 7zip (lzma2), which was a bit surprising (~0.05%). (I'm talking about APNG Assembler)

It's cool to see how things progress over time. I was reading old blogs saying Zopfli was considered "too slow to be useful". But with various optimizations and multi-threading (eg. ECT) it's very much usable. Similar to AV1.

Also the recent(ish) improvements to brotli are cool as well, shame there's no release for it yet.

RC2 at least https://github.com/google/brotli/releases/tag/v1.2.0rc2

when 10 bit jpeg?

It already exists

how to turn on it in smartphone's camera app

You can't

wow, 7z compressed a raw video (1057 mb, bgr24) to 19.9 mb archive, lossless libx265 (bgr0) - 49.6 mb, when 7z videocodec?

With that kind of reduction, is it a raw video shot with the lens cap on or something?

I guess Keynote screen record

yeah, maybe x265 would do better with very long GOP

I always wondered how good was good/slow x264 compression + avrecode

I completely change the subject, but OH MY we should see float support in FLAC soon™ https://github.com/xiph/flac/pull/842 32bit is already working, they want to also support 64bit apparently it'll take time before they add it to the spec tho, but I love this [⠀](https://cdn.discordapp.com/emojis/714771929420005426.webp?size=48&name=NUT)

64-bit seems so unnecessary

who is ever going to _store_ 64-bit floating point audio?

I guess it's for professional productions.

all they say about 64bit is > There is also the 64-bit float format (in both endiannesses) - not that it is any more urgently needed for listening, but for compatibility (edit: with DAW plugins, for example) it wouldn't be a bad thing for a FLAC plugin to be able to handle "everything" the application could save. (64-bits would likely need more than 5-bit Rice, but who cares if that element also makes today's decoders err out on something they cannot decode.) imo yeah it's useless but seeing 32bit float FLAC support is really interesting

all my music collection is in FLAC, except 1 or 2 tracks in WavPack because of 32bit float <:KekDog:805390049033191445>

working on https://github.com/google/tabuli, I’ve also used WavPack over FLAC because of limits on the number of channels

you need more than 8 channels ?

I never saw anything with more than that in the wild

3rd-order ambisonics is 16 channels for example

unlike float encoding, FLAC devs are not really interested in supporting more channels <:KekDog:805390049033191445> https://github.com/xiph/flac/issues/319

Sounds like we need FLAC XL

migu

yeah, traditional encoding formats tend to do really good when it comes to encoding raw rgb data. I wouldnt be surprised if encoding a 12bit yuv444 video will at least get closer results

Nice try but `ffmpeg -i "nothing.avi" -colorspace bt709 -qp 0 -preset veryslow "nothing.mkv"` result 8,184,265 bytes

make sure you specify pixel format

iirc you want 10bit depth

it should still prolly win tho

but it's important to remember that ffmpeg will convert to a yuv format if done like this, which is very much more efficient in x264 and x265, even in yuv444

`ffmpeg -i "nothing.avi" -vf format=yuv444p10le -colorspace bt709 -qp 0 -preset veryslow "nothing2.mkv"` result 13,901,793 bytes

In x264 preset veryslow there is parameter `--ref 16` insane for most video, but very good for this

yeee, it's nice, ~~but it's not rgb~~ still good enough for most of my uses, dunno if it applies to cioute

```console $ x264 --qp 0 --preset veryslow --input-csp rgb --output-csp rgb --colormatrix GBR --output compressed.mkv nothing.avi ``` -> 11 869 623 bytes

0.0

I wonder how good a jxl would be at storing lossless audio Like a 1x10,000,000 x 2 channel image

Or maybe a 2x10,000,000 one channel image

is converting pixel formats truly lossless? if yes, 7z videocodec is destroyed, at least it was fast

It depends, 8 bit rgb -> 8 bit yuv is lossy. 8 bit rgb -> 10 bit yuv (if done properly) is lossless.

To be on the safe side, if you are in rgb, you want to stay within rgb. If you are in yuv, you want to stay within yuv.

libavif has a wiki page detailing the off by 1 errors that come from converting rgb to yuv and vise-versa. https://github.com/AOMediaCodec/libavif/wiki/Drift#rgb---yuv---rgb-codepoint-drift

is from bgr24 to yuv444p10le lossless? if yes, then 13.4 mb h264 won

I got it down to 11.1 MB (11,700,424 bytes) using `libx264rgb`

8 bit rgb to 10 bit yuv should be lossless, but I'm not sure if ffmpeg's conversion process is accurate enough to guarantee lossless.

is from bgr24 to gbrp lossless?

you still need this file?

I think so, they are both in the same color model (rgb), therefore no conversion is needed, the difference is that the color planes are in a different order but it's lossless

I downloaded the file you posted here

Mathematically loseless YUV is possible only in YCgCo type with 4:4:4 layout and FULL ( PC ) range, when it is implemented using coding scheme what ITU-R provided, not a matrix based ( as chromium does )

i just became slightly less incompetent

Otherwise it's lossy in one way or another

is heic in android camera apps use 10 bit by default?

7z videocodec still has a chance?

Depends on what you mean by “a chance.” If the application that puts the frame in a 7z file works successfully, then you’ve done it 100%. If you mean something else, I don’t think so.

According to my numbers, using `libx264rgb` is better and can be opened in a video player, so I think 7z videocodec compression is not needed.

We messed around with lossy audio a long time ago and it worked pretty well https://discord.com/channels/794206087879852103/794206170445119489/1133208727600762921 Not sure about using such long images though, as groups are only 1024x1024 max

depends on the app but I would say that it's unlikely to be default

My take of unknown temperature: instead of trying to invent new vector file formats to replace SVG, the best option would be to just create a subset of PDF that only supports the stuff you want in an image format.

on my oneplus 12 there's an off-by-default toggle to save images as 10 bit heic instead of 8 bit heic or jpeg unfortunately the google camera app only supports saving as raw or 8 bit jpeg

Hey <@794205442175402004>, do you think it'd be possible to switch Cloudinary's free converter to use tune iq? https://cloudinary.com/tools/image-to-avif

(hopefully) it should be an easy backend change

somebody should also work on an image-to-jxl too 😉

They have this <https://cloudinary.com/tools/png-to-jxl>, but this one isn't even doing transcoding https://cloudinary.com/tools/jpg-to-jxl

These "free converters" are just simple demo apps based on the cloudinary api. Currently we're not using tune iq yet, and also not doing lossless jpeg transcoding (since usually there's a downscale or other transformations before encoding, so it would only be useful in the no-op case). I'm trying to get both things prioritized but it's tricky, there are always more urgent things it seems :). We'll get there eventually.

got you, that's 100% fair

maybe those changes are a great fit for a hackathon project 😄

but I understand the "always having something more urgent on the horizon" bit

Making the changes is not the difficult part, that's just changing a few lines of code in the backend. But any change in a system that is in production has implications, e.g. on bandwidth, cpu, cloudinary's costs and revenue, etc. Even a small change can translate to a $1m difference quite easily. That's the main thing that causes resistance to just changing stuff.

yeah, I was thinking along the lines of starting by adding the change as a feature flag for an internal account, test, and expand from there

(disclaimer: I don't know Cloudinary's API backend code :D)

small, incremental steps are the way

We always do any change like that, behind a test flag at first to do internal QA, then gradual rollout to users while monitoring (typically we start with free accounts first). It would be reckless to just do instant full rollout on anything, we have SLAs to respect etc.

that makes complete sense, and in line with my understanding

that said, `tune=iq` is meant to improve on the bandwidth/cpu/revenue frontier

if it weren't, that'd be a bad bug that needs to be fixed ASAP, and I wouldn't be doing my job well 😅

but I understand it's ultimately a matter of priorities for a company to take on

I know, which is why I'm pushing it internally. But things are complicated, e.g. reducing bandwidth is not necessarily good for our revenue since we're still charging many customers by bandwidth (this is in the process of changing, but such changes are slow, existing contracts have to be respected, etc etc). In general, at the moment it is easier to get a funky new AI functionality prioritized than improvements in compression.

thanks for fighting the good fight BTW, I appreciate (and admire) the work you've been doing 🙏🏻

Anyway, we'll get there eventually. Same with jpegli btw, we're still not using it — we started using it but we hit some Heisenbug probably related to avx512 that caused hard-to-reproduce increased crash rates, so the change was reverted and we're back to the combination of mozjpeg and libjpeg-turbo that we were using before.

I agree, jpegli deserves its place to shine

it kinda sucks that AI anything is prioritized over everything else

I've said it a few times, but there's a dozen pending PRs in the jpegli repo with various fixes and improvements. Only Eustas can approve things there though, so they've been sitting for months and the libjxl version isn't synced to the Google repo either

well there is a lot of interesting stuff that can be done now with AI, and it's getting good enough to be actually usable. But yeah, there's also a lot of hype etc.

<@811568887577444363> probably the jpegli in the libjxl repo should be removed and instead become a submodule, right? that way there's a single source of truth

I wonder whether a super fast and lightweight NN-based filter with very low/no added metadata will be feasible in the near future

the stuff that I've seen so far is just too slow

wasn't AV2 doing something like that already?

there was a proposal for a NN-based in-loop deblocking filter that had decent coding gains, but it was deemed too slow for AV2's encode/decode budget goals

there are a couple of pre-trained filters that used machine learning to derive them that made it into AV2 though

one is from Samsung, the Guided Detail Filter

https://gitlab.com/AOMediaCodec/avm/-/merge_requests/1657

the most nifty IMO, but there's barely any external documentation 🙁

Besides things that require new decode-side stuff, I think there's room for AI-based encoder heuristics to do better encoding in existing conventional codecs. With some semantic understanding of an image, more is possible than just trying to reach a uniform fidelity target in all parts of the image. Semantic adaptive quantization could be interesting. Then again, even if the AI works great, it's not in general possible to know what are the truly important image regions without knowing the context. The same image containing a car, a woman, a tree and a building will have different priorities in the context of a website selling cars, a fashion magazine, a botanist journal or an architect portfolio.

yeah, I'd love to work on semantic AQ at some point of my career

I still need to learn the toolset to get there though...

Awww, it's request to access https://www.researchgate.net/publication/395471554_Guided_Detail_Filter_for_AVM

That would be ideal, but the jpegli repo still uses a lot of duplicate files from libjxl, so I'm not sure if it would be that simple

probably requires some refactoring to put the shared stuff in a separate submodule that both of them can use, or something like that.

Equally important is making sure the training metric is good. Yesterday while in the voice channel here, I finally realised why post-0.8 was giving blurry output. Block size selection was weighted too much towards larger blocks, which made metrics better but removed fine details in the image to the human eye. We'll be working on a remediation PR soon after more testing and tuning

great news! looking forward to that change

We also still have the desaturation issue to deal with, but I think that will require a new quant table to properly fix, unless there's another control to raise the B channel's AC quality

for now, the best public documentation of GDF is from Andrey's talk: https://youtu.be/Se8E_SUlU3w?si=3lRbGozDKSiSToP_&t=1355

ideally you'd factor in luma and chroma masking into B quant for maximum efficiency (basically, give just enough extra bits to the problematic areas), but that does sound like a more complicated change

In this case the problem areas are almost exclusively the high frequency range of the B channel, so a less agressive quant table should do the trick. The issue is that for vibrant colors like pure yellow, in XYB it requires B to be at a near exact value for 0. A single value change to B in XYB turns into a 10 increase in RGB, so the aggressive quantization turns the saturated colors into a grey/white instead as they get 10-30 added to the B channel on decode

that makes sense

does JXL have a separate channel adaptive quantization mechanism? if so, you can do something like "if problematic block then boost B quant" instead of doing it globally

it might be worth investigating

but that could be left as in improvement over the global first implementaiton

No, adaptive quant weights are for all components, to save signaling cost. But it is possible to use a less steep quant table for B, or to adjust the overall amounts of bits going to B vs to X and Y, both with very low signaling cost.

What is intra encoding? What does it give?

intra is just compressing a frame independently, as opposed to inter which is using other frames as a reference, e.g. using motion vectors + residual encoding. Typically in video codecs intra coding is only used for a small number of keyframes, and most frames are coded using inter coding.

pros/cons?

https://en.wikipedia.org/wiki/Video_compression_picture_types

fast decode :D

cons?

big file sizes

Are hardware decoders not limited by bitrate? If yes, then no profit

you wouldn't want to use intra encoded video where you would use hwdecoder in any case

Brb designing a hw motion JXL encoder

Intra-only is typically used in production workflows and in digital cinema, in production mostly to be able to seek/cut at every frame without causing generation loss, in digital cinema to be sure there are no artifacts associated with inter frame coding. After all the movie will be shown on a big screen in very sensitive viewing conditions (dark room, some viewers pretty low viewing distance compared to the screen size), and compression artifacts are not considered acceptable at all. Main downside of intra-only is that the file sizes are huge compared to what can be saved with using inter. For netflix/youtube video streaming, intra-only is not an option at all, much more aggressive compression is needed than what can be done with intra-only. Inter frame techniques are great when low bitrates are needed — but they become increasingly less useful as fidelity goes up; it only works well if most residuals can be quantized away, and at high fidelity settings, the residuals will end up having (almost) as much entropy as the data itself, defeating the purpose of inter-frame prediction.

The best we could do in animated JXL would probably be quantized differential floats. Storing the difference between frames, but quantizing the difference to avoid being bigger than a standard lossy frame (pure speculation)

shrek-to-jxl is good enough

Doing the Lord's work

Cannot trust metrics. Cannot tune an image codec with a blindfold on.

Way too often, doing the exact opposite of what the metric tells you to do is how to preserve fidelity

Way too often, taking a big hit to the "objective score" is a huge win for actually being able to see what's in the image.

And I think we are at a point where image codecs are so optimized and even over-fitted to preserve good objective scores, that the only techniques remaining for big bitrate savings are probably all techniques that metrics really, really dislike. Things that would give huge penalties to metric scores. Like spectral error diffusion. Spline and noise replacement. Maybe even sone kind of contrast-adaptive quantization weighting, if that's not already done.

You are undermining the importance of metrics a little bit too much

I agree with the "blindfold" part but they are extremely important

I think, "huge" penalties to metric scores wouldn't work

And what happens when two people disagree with each other?

Metrics provide speed, objectivity, and practicality. You can't make everything be seen by a large audience.

Just use different metrics, different statistical pooling methods, or improve the current metrics in some other ways.

new jp2000 decoder https://github.com/LaurenzV/hayro/tree/main/hayro-jpeg2000

I agree that metrics provide speed and practicality, but objectivity that's mostly an illusion if you're talking about perceptual metrics. Error metrics like PSNR are "objective" in being a measure for numerical error but they are not at all correlating well with perception let alone being an objective measure of it; in fact it has very strong biases (e.g. w.r.t. image content and w.r.t. codecs).

the only objective metric is having ~100 people rate images (but it doesn't scale)

In the context of the quality issue I was talking about, SSIMU2 was correct but the other metrics scored higher with the worse result. When you have a 'good' metric it's generally fine to use it for larger changes, but when it comes down to fine tuning/fine details, the human eye still does better

As far as I can tell there hasn't been any progress in free lossless audio codecs usable by consumers since like 2006

Or how many objectively defined visual features are perceptively discernible

For example: in one codec; a freckle disappears, in the other codec it remains

But computers are bad at that for some reason right now

Hell, even humans aren't that good at it

It's difficult work

If the average person can't consistently discern a specific freckle disappearing, was it really ever that important to begin with? A unique problem when tuning for perception, do we target the average joe, or do we hyper obsess over the smallest details?

I really like how butteraugli handles this. Correct me if I'm wrong, but the standard distance of 1 is visually lossless to most people. However to us it's not visually lossless because we are trained to see compression artifacts. I think it strikes a good balance of targeting the mean perception and keeping relevant details.

wrong... e.g. there's SAC, which is quite new and beats every other codecs if using ~same compression time, and can even go really far in slowness for extra compression little benchmark here https://docs.google.com/spreadsheets/d/1sqQPgG92dSlMVi9AX2r-seiUCMO0gjL_wUTRPTIaAYI/edit?usp=sharing

but no support (except from the tool itself ofc) https://github.com/slmdev/sac/ If I had to choose a codec without looking at how good it is supported, I would go for LA (literally lossless-audio lol), very fast and compress really well

also HALAC is aimed at high speed with good compression (although it is not open source yet, it is planned when the format is finalized) https://hydrogenaudio.org/index.php/topic,125248.0.html

the importance of a feature is directly proportional to how many people discern it disappearing

This just pushes the issue from defining an objective metric to defining a measurement on whether a visual feature is perceptively discernible, which I don't think is any easier

Often, it's a matter of people not noticing until it's pointed out to them. The initial hurdle is the challenge of knowing what to look for in the first place. If you can pin down specific details and image features that actually disappear below the noise floor and become imperceptible and objectively lost and destroyed after compression, that is meaningful and that does matter. Information that was discernible and conveyed effectively in the original image, but not in the compressed image, could always be important depending on the context.

Like if the original conveys a certain texture that gets lost or changed in the compressed version. Or small details like nails, seams, freckles, or writing.

The more information at the same bitrate, the lower you can push the quality while still having good results. If detail is missing, turn the quality up

The more efficient we make it, the better quality at the same size

I think quality should be measured in terms of how many distinct visual features are preserved or wiped away

When something becomes indiscernible and disappears, that's how fidelity should be measured: how well it conveys the same information and details that the original was able to convey

If something exists in the original but not in the compressed version, that is slightly worse than the reverse situation

Because if something is missing, you never knew it was there. If something is added that wasn't there before, it's usually easy to tell it's just an artifact.

Or put another way: I think quality should NOT be measured based on "how good it looks, man" based on a casual viewing by a casual viewer.

your link redirect to HALIC which is an image codec 🤔

There's a huge difference between side by side comparison and flip test. Try a "find the 7 differences" puzzle both ways and it is obvious why it is only a puzzle if it's side by side.

Flip testing is good to test fidelity. Not showing the original image at all (absolute category rating in BT.500 terms) is good to test appeal. Side by side comparison is testing a mix between fidelity and appeal.

It must be HALAC HALIC on the encode forum for me, there is no redirection unless I intentionally click on links in a post with HALIC, from the same author

nevermind I'm fucking stupid <:kekw:808717074305122316>

I wonder about the importance of absolute position of features tho I think it would be better to have a freckle in slightly the wrong place than no freckle at all

there is a tool for flip tests in the libjxl codebase, by the way, if anyone is curious to try one

(build with `cmake -DJPEGXL_ENABLE_VIEWERS=YES`, then it’s `tools/flicker_test/flicker_test`)

I generally do flicker tests as I only have a 1080p monitor, so I can see more of the image at once than side-by-side

> WebP's downsides include: > \- [...] TV range colors (16-235 instead of 0-255), does anyone know more about this? this seems really bad if true

is 16-235 tonemapped to 0-255 or something, so you effectively have fewer bits per channel? surely you can represent pure black and pure white...

source: <https://github.com/web-platform-tests/interop/issues/994#issuecomment-3404234150>

TV range means 16 and below is pure black and 235 and above are pure white

(also TV range is an abomination that should have died years ago and it's beyond me why people keep including in modern formats)

(and I say "years" because I am not sure if I can confidently say "decades")

23.976 FPS 44100 Hz

sorry why are we doing this??

Ok basically you know how they invented CRT TVs like 100 years ago?

In those, the signal that controls the beam strength was between 0V and some other voltage. To make things simpler, every voltage below some threshold was black, and every voltage above some threshold was white.

And when sampling a TV signal, the whole range is recorded accurately at whatever bit depth

Including the over and undershoots

This is needed because sometimes the over and undershoots can contain useful data.

Then for whatever reason they decided to keep doing it that way even when TV went fully digital.

(Basically) All video formats are still TV range by default too. I was just reading about it after my friend sent a link from the VLC conference... Damn I wish I was there

...that's insane

same reason why HDMI is still has vblank/hblank periods - you can just change how the data gets into the system without any real changes to the rest of the system

tfw HDMI is literally VGA but digital and with some extra data stuffed in the blanking intervals

so, webp is still quantizing almost black to black and almost white to white like this?

no no, webp lossy "just" converts to effectively ~7.8 bits

ah okay, so it's doing this then > is 16-235 tonemapped to 0-255 or something, so you effectively have fewer bits per channel that's not *as* bad, but 8 bits per channel is already too few (as evidenced by color banding in slow gradients everywhere), and that's just making it worse

I'm actually at a loss for words lmao

who wants to help me make an 18-bit fixed point video codec? 😄

Also thanks for reminding me, just posted about the PDF announcement on there

I've leaned a lot in 10 minutes and I hate all of it

Welcome to compression, where you find out how wrong everything is so you learn how to fix it

JPEG XL: *bitdepth-agnostic encoding using fractions of an intensity target. effective and elegant, both functionally and in terms of design aesthetic.* WebP: <:banding:804346788982030337>

18-bit because FPGA friendly?

yeah

* FPGA friendly * Probably good enough for most use cases * Way more than what current codecs get you

you will need some more internal precision for things like DCT, so probably cannot really target 18-bit RGB / YUV

aye

probably 16-bit input and 18-bit internally

yeah that is also convenient since 16-bit is two bytes and byte alignment is quite practical for IO

I'm studying FPGA dev right now. Would be a cool exam project, or making a toy JXL encoder. Though right now I'm drowing in a type of assignment known as "writing reports and documentation". Teach claims the number 1 thing companies want, are fresh grads who know how to write reports, since any rando can code but few people are competent at writing report. Which seems reasonable. Still really annoying though.

you can't do large DCTs that way though

hm

who needs DCTs bigger than 4x4? :V

eh 8x8 is fine

As I recall, Pik was originally 8x8 only before JPEG asked for better low bpp support. So I suppose 8x8 only would be a decent choice.

correct

Maybe 16x16 would be fine for smooth gradients, recalling Jpegli's improved smooth gradient precision.

I mean

you work on 16 bits

you can drop a couple of LSBs 😛

for large transforms

yeah 😄

the transpose might be a challenge

on a fpga

more than the precision, I mean

hm, yeah

I guess the only way I'll find out is by experimenting. Writing that darned report in Microsoft Word comes first though.

WebP hate still going strong in the mainstream, although there is some push back now. https://fixvx.com/stupidtechtakes/status/1984989563736191253

>stupid tech takes

nomen est omen

don't know what the common pushback is but IMO it should be nuanced

but seriously, that list is incredibly stupid

the crazy part is that there is content out there that has significant information above 235. iirc severance in sdr goes above 235 quite a bit? so while 235 is the nominal peak, tvs do show things beyond that. but on any normal pc setup it'll just be clipped

The hate is just a trend without anything technical

"I hate because they hate"

Many complaints from the thread are also outdated. still with the old "nothing supports it"

webp images identifying as jpegs with fake file extensions hasnt helped

I think webp hate is 100% justified. It was a very half baked format no one asked for but was forced on everyone with all its known flaws, by the same man who says that there's "no wider community interest" in jxl

webp interest wasnt even real, its mostly served by cdns and for resized previews of the larger originals. its use will collapse down to almost zero when better is available - and i dont mean aivif, even though it was the designated successor of webp

All my productive softwares support WebP

Those "artists" who shall use Clip Studio Paint the most... it supports WebP completely as well

CSP can make animated WebP too

Try to upload WebP for YouTube thumbnail

Google is super arrogance that YouTube auto convert thumbnail to WebP, but user can't upload WebP for thumbnail

I don't want to blame Google for its dissociative identity disorder

We know they have serious bureaucracy problems tbh.

Chrome team still fighting with JXL team.

I like how the immortal elves, fairest and wisest, get JPEG

I know there's still probably some decent gains to be had out of the jxl bitstream but is there any thought of a successor? What would even change if so?

its already futureproof today and there's a lot of room to think of new limits for higher profile levels in the future

stable bitstreams with such massive breathing room simplifies decoding, onus is on encoders and workflows to improve their encoding efficiency

there's *plenty* of things in the bitstream I'd love to have done differently, but nothing that makes me hope for a successor any time soon 😛

I asked something similar a while ago and got some interesting responses https://discord.com/channels/794206087879852103/794206170445119489/1336029940570656808

<@794205442175402004> missed deleting this one

weird, discord's auto delete on ban feature must've messed up

deleted

I had assumed it would happen with time but nope 😛

So in other words, lots of relatively minor nitpicks but nothing too big? (I suggested this earlier but, could always do some unofficial/optional "variant" bitstream with those little nitpicks addressed, and hide the encoder behind a bunch of runtime and compile-time flags so normies don't accidentally encode with it)

Cool visual improvements from SVT-AV1-PSY at the VLC conference

BTW, you can <@703028154431832094> and me anything about the presentation, or VDD in general

I hope recordings will be available soon

I'm looking forward to reading about the motion vector based gaussian splatting too

Is webp better than jpeg in term of smartphone photo?

Yes

generally yes, though if I remember some highly tuned JPEG encoders are competitive? I remember <@794205442175402004> mentioning this

It depends. For high quality, just stick with JPEG, ideally JPEGLI, due to WebP's TV range and forced 4:2:0

it depends on the quality range you're interested in. For the low end ("web quality", not including the more high-end web applications), WebP does outperform JPEG. At the high end ("camera quality"), WebP is inferior to even just libjpeg-turbo. In the region between those two (high end of web quality, low end of camera quality), WebP is comparable to libjpeg-turbo and worse than jpegli.

> it depends on the quality range you're interested in. For the low end ("web quality", not including the more high-end web applications), WebP does outperform JPEG. also worth noting that JPEG does however support progressive decoding which is nice for people with slow internet connections. WebP does not (to my knowledge). the Lighthouse score isn't everything!