JPEG XL

What about prediction modes? Can in principle all modes allowed by the bitstream be used in av1 encoders, or are there some that they do not even try so will never be used?

That I do not know. I have not analyzed any of the speed features/specifications to know the extent of what prediction modes can be used.

It's quite hard to estimate a bitstream's potential

Which is why usually reference implementations are very slow and exhaustive, to make sure they're as close as possible to the real potential of the bitstream

(then later trade-offs and shortcuts are made)

With cjxl that is not really the case: even tortoise is quite far from exhaustive, doing things exhaustively would just be infeasible

I wonder to what extent it is the case with libaom at slowest setting

How would I go about creating a yuva444p AV1 video (from RGBA PNGs)? (<@!321486891079696385> ?)

I don't think the av1 bitstream itself supports alpha (otherwise why wouldn't they do that in avif?)

so likely you encode a yuv444p av1 for the color, then a yuv400p av1 for the alpha, and then do some container muxing magic at the mp4/mkv level

Well, guess I keep using animated WebP then. Even if that's an unpopular choice here. 😛

avif is better because it doesn't force 420 sampling but no firefox support

I like the fake noice feature

But that's more for Videos.

I hate how an Anime Blueray is 2 Gigabytes Anime and 18 Gigabytes noice.

Ok depends on the Anime...

Most old animes that you get in europe have bad quality.

Better than DVD, but I can still get them to 2 Gigabytes compresses with VP9...

That does not work for sharp anime...

Yes, they do.

The best I've seen was 70mbit/s H.265

But in most cases you really don't need it.

Nope they don't.

Anime blu-rays are still massive, and yet, most of the time, they are full of artifacts and aren't native 1080p for example.

You still have to waifu2x them sometimes....

540p, 720p, 768p, 810p, 900p are the most common resolutions.

Most of the time, even today(mainly for shows, movies are a bit less problematic) mastered anime is not drawn natively at 1080p.

For example, my Hero Academia is drawn at 720p.

Also, most of the best anime BDs actually come from Italy funnily enough.

https://thumbs.gfycat.com/TartWeakBigmouthbass-size_restricted.gif

Yeah it's nice.

Just encode it to reallly low bitrate

Add fake noice.

Done

*sarkasm*

this one seems to be at ~10-15 Mbps for the video stream

h.264, 4:2:0, 1920×1080

Yeah but they take 90s Anime (made for analog TV), and encode it with about 40 Mbps

Not madoka magica?

that's Madoka Magica

Puella Magi Madoka Magica (Suitable for children 😛 )

well, the first couple of episodes, at least...

https://www.reddit.com/r/AV1/comments/o3ips4/a_fine_balance_of_compressing/

Anyone feel like doing a variant of that where in the first panel it's avif doing the compression, and in the last panel you see a 0.02 bpp avif?

lemme try

btw doesn't twitter not compress images as much anymore?

or at least you can get the original

Twitter changed some things, in some cases they don't convert png to jpg anymore

I don't think you can get the original, I don't think they keep those around

I think they also don't recompress jpegs anymore

As long as they're under 5MB and under 4096x4096 pixels, they will still show recompressed previews on timelines but you can click on them to get the original.

If it's a jpeg.

For png, I think it converts to jpeg unless it's a png8 (palette colors) or has alpha.

This has lead to people making images with one transparent pixel just to prevent twitter recompression (which is kind of annoying to deal with, I occasionally have seen such images outside twitter and it's not so great to have such fake alpha channels imo)

how's this

Excellent!

Mind if I tweet that?

Can credit you of course

sure thing

CC BY-SA 4.0

How should I credit you? "190n"?

i'm @_190n on twitter

Ah maybe you want to tweet it then, I retweet?

ah you can tweet it idc

don't use twitter that much

So, it seems like someone's been working on improving FLAC further: https://hydrogenaud.io/index.php?PHPSESSID=rfkklc5eh13e71h7j35s7eb7u1&topic=120158.msg999524;topicseen#new

<@!321486891079696385> I've got an idea for AV2, wanna read?

Yes.

Nice.

Okay... how much do you like chroma subsampling?

I don't.

Nice.

Just like Opus ditched the idea of keeping the original sampling rate (it saves it in a tag that can, but doesn't have to be respected by decoder) and does everything internally in 48 kHz, AV2 should ditch the idea of keeping chroma subsampling (it could save it in a tag) and do everything internally in 4:4:4.

From what I understand, AV1 has (just like previous codecs) special coding "modes" for 4:4:4, 4:2:0 etc., am I right?

Are you alive Blue?

Yes to both questions 😛

Anyway, I can't always answer stuff on time because I have work to do <:kekw:808717074305122316>

I'll write a bit, you'll read when you have time 🙂

So AV1 has special coding modes for different subsamplings, AV2 will have none (in my project). The only thing subsampling of the source material will do is change the "source subsampling" tag I've mentioned before and affect encoder decisions a bit.

makes sense. just encode that stuff in lesser quality. subsampling is very crude way to get that

I know, I'll get to that.

There will be no more nearest-neighbour upsampled chroma (like in the image below, particularly visible in reds) since squares are hard to encode with DCT and it just looks awful.

http://www.johncostella.com/magic/replicate.png

Reference encoder should first upsample it with a better upsampling algo, something like Magic Kernel Sharp+ from the original article (http://www.johncostella.com/magic/) should probably do the job.

http://www.johncostella.com/magic/fancy.png

yeah, YUView allows to choose the method for chroma subsampling (iirc between nearest neighbor and bilinear), and it makes quite a difference

Yup, but there's even more to my proposed AV2 project than just smarter chroma upsampling algorithm 🙂

of course 😄 it was just a small aside

AV1 already has the second part, it's CfL prediction. If the AV2 encoder knows that the source had subsampled chroma, it should completely ignore the error between upsampled chroma and CfL prediction in respectively highest DCT coefficients and assume that CfL predicted them perfectly (like in <#824000991891554375>). It'll probably result in sharper chroma in sharp luma areas, wouldn't it?

This is something an AV1 decoder could actually do already if it would decode to yuv444, right?

Actually yes, damn

I've just noticed in Squoosh that AVIF indeed does NN upsampling (whyyyyy <:NotLikeThis:805132742819053610>), while MozJPEG chroma was smooth no matter with or without chroma subsampling.

Fortunately it'll be simple to implement better chroma upsampling in AV1 decoders.

And thanks to Jon I've just realised that those things that I've planned for AV2 encoder can be applied to AV1 decoder (with a bit worse performance, but still).

Decent chroma upsampling should be a no-brainer in any decoder, but I think how well would CfL-based "fake hi-res" chroma work...

I have 4k smartphone video, if i want to encode it in 10mb fullhd, it's better to do it in av1 444 or 420?

420 10-bit

Why 420? <@164917458182864897>

i thing there is quality trigger then 444 is better than 420, or maybe near all the time like jxl? 😄

For 10bits we know it better in all cases in all video format 🙂

444 is unnecessary for most video content (at least video recorded irl, which this is), and it's less compatible with hardware decoders

https://discord.com/channels/794206087879852103/803574970180829194/852206410615881728

looks like that's for images?

4:2:0, since the video is already in 4:2:0.

4k video 4:2:0 is equal in color in 4:4:4 fullhd. I have no solution to flip video to test visual quality. That's why i ask the question. I hate color subsampling.

https://www.youtube.com/watch?v=1aKwFVwGoUE

Downscale only luma and keep chroma as it is.

So, AVIF lossless has improved a lot these days, but it's still not enough to beat WebP, let alone JXL. Funnily enough, for best encode performance, single-threading actually makes lossless **worse** in many scenarios. I wonder why actually. Also, from my decoder testing for the article, using AVIF lossless is basically a death sentence for decoding performance.

Example encodes

also does AVIF lossless use 8ibt YUV here? (how can i check?)

ah. found `avifdec -i` ``` * Bit Depth : 8 * Format : YUV444 ```

so I guess this will reduce colors unlike with webp/jxl

huh it doesn't? interesting

depends whether source image used actual full RGB range or not

i kinda always assumed that full RGB->YUV is sorta lossy but does color loss actually happen in practice?

nice image 😄

Yes, YUV444 has less precision than RGB24

Not if lossless mode is activated.

Lossless mode does transformations at much higher bit-depth to prevent these sort of YUV lossless, and as such, is mathematically lossless.

Of course, because of the huge decoding speed penalty, I would only recommend using lossless AV1 in video.

So it is using 10 bit YUV for RGB24?

Lossless does everything in 16bpc.

~~Oh no, I don't think it's mathematically lossless for RGB source <:monkaMega:809252622900789269>~~

huh so it's actually lossless or not idgi

I don't know.

However, I used a bad example 😔

I just checked MD5 checksums <:kekw:808717074305122316>

How would I actually verify if it's actually mathematically lossless? <:Thonk:805904896879493180>

`compare -metric AE` apparently can do this but im unsure should look it up what it does exactly

avif-lossless --cicp 2/2/0 or 1/13/0 > Setting the matrix coefficients to 0 (Identity) says that you don't want to use YUV, but that you just want to pack the RGB values directly into the planes (in the order GBR), > It is currently the only way to truly achieve lossless encoding at the same bit depth as the source image.

in my experiments with it it does actually return zero but idk if that's proof or im just lucky with my images

I checked.

All images are lossless, with AVIF, JXL, and WebP.

All the same size, not a single bit difference.

Actually, there's a problem.

The JXL image is actually a few bytes bigger.

djxl png will include srgb icc profile?

Does anyone know of any other discord servers dedicated to a media codecs?

ooh I just found the AV1 discord

best way to check lossless is not filesize but doing something like `compare -metric pae orig.png decoded.png null:`

normally, only the sRGB chunk

we can use something like http://entropymine.com/jason/tweakpng/ to look at exactly what is there

this is how I noticed the imagemagick oddity with the missing sRGB chunk

(iirc it works well in wine)

For simple stuff, I find this one good too: http://www.libpng.org/pub/png/apps/pngcheck.html

https://twitter.com/kornelski/status/1407732715433119746

Good that FOSS avif encoders are getting improved

libavif 0.9.2 > https://github.com/AOMediaCodec/libavif/blob/master/CHANGELOG.md

Yes, If you don't specify -j N only use 1 core.

I think you get worse compression though with avifenc when using more threads

you certainly do not get the same result with different -j values

(it's different from cjxl --num_threads in that respect, which does give you the same result regardless of how many threads you use)

I think they create more independent tiles when using more threads

Not consistently true funnily enough, especially in lossless. As well, threading in aomenc is just using row threading, which works really well in intra compared to normal video coding, and no need for tiling until you hit >4096x2160, and purely independent tiles when you hit >35MP if you actually care about HW decode in the future for most stuff, which you shouldn't really outside of camera apps.

Of course, once you get an image above 4096x2160, avifenc will swiftly switch to using 2 tiles and up and again to confirm to tile size specs.

even with a small image, the output I get for `avifenc in.png out.avif -j 1` is not the same as the output I get with `-j 2`

Normal. Row threading(or wpp threading) is not fully deterministic.

kind of weird that the encoder is that nondeterministic though

Yeah, intra-only is more affected by this than normal video coding. Anyway, thank you yesterday for telling me about IM's Compare tool.

I was able to verify that way that even the very slightly bigger JXL file was lossless.

Did anyone try to measure the density/quality impact of using multithreaded avif encode?

Is it only libaom that behaves like that or also the other encoders?

Only SVT and aom behave like this. rav1e is the one that gets affected the most, since it only has access to tile threading.

Anyway, you just made me doubt myself about the threading stuff <:Thonk:805904896879493180>

testing default avifenc on some random image: 1 thread: 1330327 bytes, 3-norm: 1.226357 2 threads: 1334347 bytes, 3-norm: 1.227158

not a huge difference, but not really insignificant either

so, bigger and worse rip

Well if there is a difference in result when doing parallel, it's always going to be doing less global optimization to get more speed, i.e. get bigger and/or worse.

true. not very surprising

In cjxl we avoid that and only parallelize what can be safely parallelized (but that means less than linear speedup)

especially at slower speeds

I measured `cjxl`’s speed with 0/4/8 threads at various speeds the other day and got something that looked like this: ``` -s 1 -s 3 -s 5 -s 7 -s 9 --num_threads=0 34.5 29.68 20.39 5.56 0.26 --num_threads=4 68.55 62.88 41.75 10.36 0.28 --num_threads=8 81.39 78.39 46.98 11.81 0.28 ```

(unit is MP/s)

You need a large image to get speedup from many threads too - at least one dc group per thread or you cannot really use all threads for the dc part

Dc groups are 4 megapixels big

The histogram / context map is I guess the main thing that doesn't parallelize at the faster speeds, right?

I suppose we _could_ do that less globally and sacrifice some density for speed. At least it's entropy coding only, not quality-changing.

wow I had this older libavif/libaom lying around: Version: 0.9.0 (aom [enc/dec]:2.0.2

now using latest from git: Version: 0.9.2 (aom [enc/dec]:v3.1.1

did the same command with both of them: `avifenc -s 6 -j 1 -y 420 --min 0 --max 63 -a end-usage=q -a tune=ssim -a cq-level=24`

old version took 48 seconds to give me a 2.1 MB avif file

new version took 11 seconds to give me a 977 KB avif file

yeah but the 977 KB avif file does look a lot worse too

if I want to reach the same butteraugli score, I now have to go all the way to `cq-level=9`, and that gives me a 2.2 MB avif file

but only in 10 seconds

so it is 5 times as fast as before, but a bit worse in compression on that example

I'm mostly curious how the scale changed so dramatically, that what used to be cq-level 24 is now cq-level 9

anyway, default cjxl using single-core takes 3.5 seconds on that image to produce something with a better butteraugli score than the 2.2 MB avif, but in 937 KB

The quality may be higher or the same without `-y 420` (at least in my tests and not at the lowest bitrate), also min=max can increase the encoding speed, but it is harder to achieve the required size

i'm using 420 mostly because I'm not sure that 444 will remain supported once hardware starts to get used

at least that's what happened with heic

444 heic files worked fine in Apple devices, until they enabled hw decode and now only 420 works

sounds v rude way to "support" stuff

well we'll see, maybe I am too pessimistic here

i doubt non-apple stuff have as tight integration w hw so i wouldn't be so pessimistic

yeah, they'll need software fallback anyway so it'll probably work

might become a "bad practice" though to use av1 that requires software fallback

i wonder if it could end up other way around, hw decoders supporting 444

Is AVIF hardware decoding already used in browsers or is it for the future? And I think to decode AVIF correctly, it would require some sort of tile splitting like in HEIC (unless it's the only single large image)

im not aware of any use so far

hw decoders currently announced are all 420-only afaik

I don't think browsers are doing hardware av1 video decode yet even

Yep, mostly Main profile (but at least with 10-bit support, which can also may increase quality even for 8-bit source, but it's slower for software decoding)

444-only AV2!

Just one data point of course, but at least in this case (the p06 image, at around q75), we have jxl being 3x as fast as avif and 50% smaller. <@532010383041363969>

BTW, I actually do not recommend tune=ssim.

It may increase detail retention in some spots, but it hurts color quite a bit.

What are the settings you would recommend?

Did you compile aomenc with butteraugli tune support?

Let me write my usual settings in <#840831132009365514>

Ok thx

I didn't. Is it fast enough for 'reasonable time' encoding?

Ye.

when I tried tune=butteraugli (not on many images, admittedly), I didn’t actually find it better than tune=ssim, it was slightly worse

(and also produced worse butteraugli p-norm…)

Odd, I find it improves stuff on most images. Granted, it has different tradeoffs vs `--tune=ssim`(most are better color preservation with the butteraugli tune in exchange for less detail retention), but I feel the tradeoffs are in a better direction.

Pasted something something about AVIF encoding: https://old.reddit.com/r/AV1/comments/o7s8hk/high_quality_encoding_of_avif_images_using/ Criticism, discussion, and corrections welcome <:Stonks:806137886726553651>

how does tune butteraugli compare with tune vmaf?

Supposedly there was a terrible bug in tune butteraugli until the most recent version of aomenc

oh, yes, that might explain it

I have not tested that yet. It would be an interesting test to do on a few images/test set <:Thonk:805904896879493180>

I still need to compile VMAF on my production ready system, since my bleeding edge OM install broke...

The WebP file is 330kB. The JPG file is 3,3MB 👀

So yeah, much lower bandwidth costs.

This is an extreme example though: most WebP images on the web are a bit smaller than the JPG ones.

Heck, I'd say the smart thing would be to run mozjpegtran on every JPG that comes in.

It's pretty fast, and gives a free efficiency boost.

Actually, why doesn't every website that accept raw JPEGs do this <:Thonk:805904896879493180>

Both image look so bad...😢

tbh i prefer dithered one but that's just personal preference they both look bad

anime stuff just looks better with clean lines even if colors are dotty

do they not give the original at all?

surely we can do much better, even for a color-reduced PNG

(how did they choose the palette?)

That is a good question. However, I do not currently like using tune vmaf_without_preprocessing, as VMAF stuff is currently single-threaded in aomenc, which means it's a massive latency bottleneck in encoding <:monkaMega:809252622900789269>

tune vmaf_without_preprocessing is so much slower than butteraugli it's not even fair(tune vmaf_without_preprocessing is a pure quality based RD tune, absolute no shortcuts taken) to compare them, but here's my image set(the large resolution image set with vmaf is still not done <:monkaMega:809252622900789269>).

Photographic image sets

Command line for each setting(except for the tune obviously) `avifenc -s 3 -j 2 --min 0 --max 63 -a end-usage=q -a cq-level=18 -a tune=vmaf_without_preprocessing -a color:aq-mode=1 -a color:enable-chroma-deltaq=1 -a color:qm-min=0 -a color:deltaq-mode=3`

that just looks like screenshot tbh so you could probably find it by going thru anime. i think. unless its special material which ended up not included

which reminds me i started watching this one and havent went thru rest of it because got busy with things

i think it may b still airing

also tbh for stuff like anime things, idk if theres much interest, id rather poke things which do big on images like fb (already interested), maybe twitter, maybe tumblr, maybe uhh how was that one for photos called

it kinda makes sense for them to be enthusiastic about it

as they may gain big savings from jxl

i suspect BDs may not be yet out for this one but approach makes sense in general

jxl can't do any generation loss

is all marketing

is all anticipated marketing

jon adviced to make wikipedia articles and many things at random people that always are online

webp2 is what you better use for the web.

EVEN jon and cloudinary marketing has said until you aims at bitrates lower than 0.636 bpp so less than visually lossless in a flip test (basically what you get with this command (-s 9 -d 1 --use_new_heuristics with libjxl v0.3.7-169-g1f7445a win_x64) you shouldn't use it

if you think this command isn't good, wait for final release before judging generation loss or web capacity.

or get a better source

don't rely on ac strategy

Webp2 is good at 0.636 bpp?

i'm using images of jyrki to illustrate it

Which is webp2?

That's not what I said. I think below 0.3 bpp AVIF is better, between 0.3 and 0.5 bpp they are similar, and above 0.5 bpp JXL is significantly better than AVIF. Or at least current encoders behave like that.

this is d 3 epf 0

PNG looks better

webp completely blurs all of the grass 😄

they used too low quality

while WebP has this tendency to blur green and red objects, it is not usually this bad

highly saturated colors get too few bits in YUV color modeling (this is solved much better in XYB, and also in Lab)

that's why reds and greens look weird on video

perhaps particularly so for magenta and red

(with webp I also observe that dark greens and browns get rather blurry)

I tried to get colors right in JPEG XL, to have balanced amount of quantization there in different base colors

it started by first having a corpus of images with all the possible base colors, each with some subtle details -- both in color and intensity

what I didn't have, I pseudocolored...

like this rose doesn't exist

IIRC, I swapped the red and blue channels for it

> But to verify this claim, is it still accurate if you use a test data of lossy images (and many of them may not be -q 99 high quality JPGs)?

no one knows...

we don't know what is the correct switch point from VarDCT to lossless jpeg recompression for original jpeg quality

I anticipate if original is quality 90, we'd likely want to VarDCT-code it -- and if the original is quality 50, we'd like to lossless jpeg recompression it

where the cross-over point exactly is, I don't think anyone looked into it

can also be different for yuv420 and yuv444

if VarDCT coding, it might make sense to 'restore' the quality of the original using knusperli-like approaches

one this is sure the 169 -g (i don't remember build)

that one don't look good with explicit images, let alone anime

the ac strategy is too flat

those images also are usually low quality sources

but we want the encoder to advance and the images not looking like floorings.

improvement comes in small steps

share the most problematic images with their results (only d and epf settings, please)?

good

So, there may be new interesting or improved compressors from past challenges (including image compression and open source) <https://gdcc.tech/>

> `JXL_FAILURE: APNG with dispose-to-0 is not supported for non-full or blended frames` is there a way in ffmpeg to produce APNG files that don't use dispose-to-0?

We could also just implement that in the apng loader, I guess

<@!321486891079696385> how does local palette work in AV1?

As far as I understand, you can use a palette of up to 8 colors per channel, but I have no idea how the pixel data itself is encoded in palette blocks

the problem with audio is that i want appeal as 177 kbps nero ABR in lower quality and that doesn't happen with no encoders encoders aren't tuned for that

use opus

i just wanted to try exhale at 64 kbps

preset 1

maybe is better with sbr

exhale much better with sbr

please don't encode in such awful bitrates

at all bitrates exhale is much better with sbr

afaik libfdk_aac is the best open-source AAC encoder

(old-style AAC, not the new extension)

id just use vorbis or opus, aac is sucky

(also not high-efficiency)

vorbis is actually worse iirc

than fdk

aren't they pretty similar? i kinda forgot when i read about that stuff

yeah, I need to look again

there's also aoTuV patchset for vorbis which I have installed idk how that compares

in https://listening-test.coresv.net/results.htm, at 96 kbps, aoTuV lost to Apple’s AAC encoder

but at other bitrates, or to fdk, possibly not

https://hydrogenaud.io/index.php?topic=120062.0

> • Apple’s AAC encoder (QuickTime, iTunes) really plays in a different league. Quality is outstanding and it outperform the competition.

https://hydrogenaud.io/index.php?topic=117247.0 and there someone saying that they prefer vorbis lol

in any case, it indeed seems that roughly everybody agrees that Opus is the grand winner

my one annoyance with opus is that opusenc only has bitrate-based quality control

no `-d 1` equivalent

looking at https://listening-test.coresv.net/results.htm they come pretty close too. but yeah opus looks better everywhere

Follow-up to this: https://discord.com/channels/794206087879852103/794206170445119489/861635017348218890 The trick to make noise synthesis as good as possible consists of doing 4 things if you want the highest quality implementation in addition to all of the other things that have to be done normally: 1. Variance based analysis. Areas with higher frequency blocks need less noise generation than those with lower frequency blocks, but require higher bits/block(such an analysis can be decently substituted just by using variance based adaptive quantization during the normal coding process). * 2. Good edge detection. Edges need to be detected as to preserve them as well as possible and to not apply noise to them(otherwise, it might look artifacty or if denoising is activated, line removal). 3. Good powerful temporal 3D denoising for the noise estimation, but **not** applying it to the source image. Any kind of denoising to the source frame is not very good, which is why the `--enable-dnl-denoising=0` option in aomenc was introduced by yours truly with the help of some friends: does not denoise the source input, but denoises during the calculations. 4. Film grain size estimation. Intensity and type analysis is already done, but size is one of those things that's rather important. Currently, only SVT-AV1 gets close to a "great" implementation by doing 1-2 and a bit of 4, but aomenc only does the 3rd one(and not denoising the source picture), but not #4, and nothing for #1 and #2. * During the normative analysis of the grain synthesis parameters, an operation similar to that is done to estimate the grain parameters, but it is only done at 32x32 block levels, and not SB(superblocks) level/frame-level, resulting in some weaknesses for aomenc in animation type content with grain synthesis.

Does this command decode to pixels or not? `avifdec -i test.avif` I need the same this does without the output file `djxl test.jxl` Trying to compare the decoding speed of the avif/jxl files.

To decode to pixels, you need to do: `avifdec --info input.avif`

Also, for optimal decoding speed, a binary built with libyuv(fast YUV path) is recommended.

It makes a non-negligible difference in this regard.

`-i` and `--info` are the same, according to the help 😄 So it does decode. Thanks.

Fast libyuv also makes it so that you can decode JPEGs directly to raw data without any independent step, skipping chroma subsampling to 4:4:4/4:2:0 again.

Could someone pls share AV1 Discord invitation?

Found it…

Updated PNG Optimizers Benchmark from the Pingo creator https://css-ig.net/benchmark/png-lossless

is impressive it reduces to 47% from webp reddit

at lowest quality

if you convert to jpg quality 100 with xnview

to lossless png at maximum effort it only reduce to 10%

compared to xnview

14.845 kb to 13.632 kb

Great!, pingo -pngcolor is back to command manual, 🙂 but look like pingo still force transfer 16 bit depth png to 8 bit depth...

got a JPEG1 question that's above my pay grade: For higher pixel density versions of images (eg what you'd serve to many phone screens) you can set the quality a bit lower without as much perceived loss. Some old discussions on the MozJpeg issue tracker (<https://github.com/mozilla/mozjpeg/issues/76#issuecomment-68163040>) suggest that when doing this you should use the quantization table tuned for MS-SSIM. Is this (still) true? Any other settings you should use when doing this (e.g. also tuning trellis optimization for ms-ssim rather than the default of psnr-hvs)?

That is true. For photographic image, MS SSIM is superior as a trellis RD tune. PSNR HVS is better for everything else.

Okay, thanks 🖤!

Generally you need relatively less aggressive low freq quantization, because banding becomes a bigger issue than dct noise

Oh followup question: is there a decent way to use butteraugli in this case? comparing as-is but using a higher target number? downscaling both and comparing that?

i'd like to have some perceptional target number to hit

Yeah, that works but it is a bit of a bruteforce approach :p

got bored and made a graph from a grand library of 1 (one) test image, so absolutely no statistical significance size of image compressed with various quantization tables vs butteraugli score of the half size version of it vs the half size version of the original

interesting jump at 700kb, is that the q90 threshold? (420 vs 444)

Yup!

https://matthorn.s3.amazonaws.com/JQF/qtbl_vis.html

demo of https://arxiv.org/abs/2008.05672

hah, "visually indistinguishable"

on eg. parrots it creates a nontrivial amount of blocking from what I can see

(with their own side-by-side comparison)

speaking of brute-forcing, the best results (as in, lowest file size with a 3-norm at or below 1) i'm getting thus far are by disabling chroma subsampling and then using different quality settings for each channel

takes a fair while to calculate those though as i'm currently just doing it all via a very hacky script. there's probably a way better way to do all of this but _shrugs_ this ain't really my area

https://eclipseo.github.io/image-comparison-web/#reykjavik*2:1&JXL_20210715=l&AOM_20210715=l&subset1 Look in this picture, avif mozjpeg heif webp webp2 seem to have a gamma problem in lossy, you know why? jxl is good 😄

wow avif absolutely destroys grain even at large preset

also yes it makes stuff whiter i wonder why

something weird in the PNG original

maybe that gAMA thing again

https://news.ycombinator.com/item?id=27925393

<https://games.greggman.com/game/zip-rant/>

its a shame arithmetic coding isnt implemented anywhere given how many pages of the spec it takes up _has been reading it to try to broaden her understanding and is currently regretting not ripping all those pages out a day ago with how much she's had to scroll past them_

it's cool that it's being utilized nowadays, and in not form what is slow like it used to be back then

in new formats i mean

The AC in the 1992 jpeg spec is not that great anyway, without context modeling etc it's basically just like huffman but with more accurate distributions...

also interesting that 16 bit quantization tables appear to be a thing thats used when 12 bit samples arent and the spec says they should only be used for those

the bit thats hardest to wrap my head around thus far is the encoding for successive approximation of AC components the initial scan is easy, just divide the coefficient by 2^n on subsequent scans, if its the 1st scan the coefficient isnt 0, you write huffman(zero run length + a magnitude fixed to 1) + a sign bit + a correction bit (which does... something) and if it _isnt_ the 1st scan the coefficient isnt 0, then... i don't know

ah okay, the correction bit is just the bit thats in that place

and for every coefficient thats had a non-0 encoded in a previous scan, you just append its current bit to the end of the scan data?

<https://chromium.googlesource.com/codecs/libwebp2/+/1101a08f70f5da82e67a9ffd890d11b0bdb1f11b> > Add minimal AVIF parsing and writing > > The goal is to demonstrate the possibility of storing necessary image > features into a lightweight container/header, which is easier to parse > and write than AVIF/MIAF. The contained AV1 OBU bitstream is kept as > is for now, but may be reduced too in the future. 🤔

interesting

isn't webp2 based somewhat on av1? maybe their encoder could be extended into a better avif encoder

I guess more interesting as far as input to JXL encoder is concerned than as a competing HDR-ready web delivery format: https://lists.w3.org/Archives/Public/public-colorweb/2021Jul/0003.html

<https://encode.su/threads/3422-GDC-Competition-Discussions?p=70468&viewfull=1#post70468>

Interesting review article on the evolution of lossless compression (images may not load via GTranslate and it is better to use browser translation) https://translate.google.com/translate?sl=ru&tl=en&u=https://habr.com/ru/post/570694/

> And about 10 years ago Asymmetric numeral systems appeared(ANS), which made it possible to achieve the compression ratio of arithmetic at the speed and computational cost of the fast Huffman algorithm, which since 2013 has led to a small revolution in fast practical algorithms. Note that it took 30 years to create a fast version of the efficient algorithm. ANS is now used in the libraries Facebook Zstandard, Google Draco, JPEG XL and many other recent developments. Note that ANS author Jarek Duda is a member of the expert council of the new compression competition, which will be discussed below.

> ... > In this regard, it is very gratifying that commercial companies (and primarily Google) in the last 10 years have begun to regularly publish suitable implementations of lossless compression libraries in open source (see Google Snappy - 2011, Zopfli - 2013, brotli - 2013, PIK - 2017, Draco - 2017, etc.). > That is, development proceeds by steps, first a new idea appears, giving another leap in benchmarks, and then its industrial implementations are gradually being pulled up (more often - closed, but sometimes open).

http://www.jbkempf.com/blog/post/2021/dav1d-0.9.1-a-ton-of-asm

> This is very large for handwritten assembly, and for comparison, this is more assembly than what there is in FFmpeg (for all codecs)

It's as fast as it gets now

Handwritten asm for all important code paths and platforms, it doesn't get any faster in software

they mention remaining improvements for the threading model, not sure how much it matters for that

pretty impressive LOC...

I wonder how fast jxl decode would get if effort like that is spent on handwritten asm using fixedpoint

And how much smaller the decoder will become with C+asm and also further development may be in the direction of using the GPU to get more power efficiency (not sure about speed)

It can only get smaller if you can distribute for a single target, if you need to have the separate code for each cpu target it gets larger, not smaller

my guess is "not that much"

maybe 25-50% depending on the platform

but it's a guess

and likely it's not very different from what you'd get with fixpoint using hwy

But this is from 2019 (and perhaps a big difference because libaom was originally not very optimized for this purpose)

https://chromium.googlesource.com/codecs/libwebp2/

two commits

not important ones

https://tenor.com/view/destroy-undertaker-tongue-out-wwe-gif-15650864

I do some test with last avif encoder in animate image, so it destroys jxl in terms of size, it is indescent.

For animation, av1 or even h264 will beat jxl any day

If interframe tools are useful

not very surprising, the JXL encoder nowadays doesn't even try to do frame prediction xD

cjxl is bad at using whatever coding tools jxl has for animation (doing even less than an apng encoder like apngasm or imagemagick convert), and those tools are limited compared to real video codecs

more than "bad", it doesn't even try...

yeah, if starting from a GIF, running `gifsicle -bO3` on it beforehand is useful

it will make the GIF update the minimal rectangle necessary in each frame

and `cjxl` will reuse that (iirc)

Yes, same with apng, it just reuses the frame rects from the input

https://www.reddit.com/r/compression/comments/onbb8q/project_image_compression_with_loss_based_on_the/

https://raw.githubusercontent.com/giacomo-ascari/dichotomic-compression/main/docs/examples.gif

Interesting at least.

As a complete codec it may not be enough, but as part of some algorithms it may be interesting for images with large solid color areas, although perhaps modern formats use something more efficient

VarDCT block selection is kind of the same concept

Also, 256x256 VarDCT blocks can improve efficiency mostly only at very high resolutions?

Currently the encoder only produces up to 64x64, bigger blocks would make sense even for not so huge images but it's a bit tricky to cross chroma-from-luma macroblocks in the current encoder heuristics (CfL multipliers are given by a 1:64 aux image)

Note that for a 256x256 block, we already encode 32x32 of the low frequency DCT coefficients as part of the 'DC' image. So it's a DCT with 65536 coefficients but 1024 of the lowest frequency ones are signaled already.

That's still a huge amount of coeffs left, and it only makes sense to use such a big block if they're mostly zeroes

(but they don't all have to be zeroes, e.g. you could have something like a stripe pattern represented by a relatively small amount of nonzero coeffs)

As of Nov. 2020, WebP 2 is only partially optimized and, roughly speaking 5x slower than WebP for lossy compression. It still compresses 2x faster than AVIF, but takes 3x more time to decompress. The goal is to reach decompression speed parity. Side-by-side codec comparisons can be found at: 2021-07-13 2021-07-01 2021-06-08 2021-04-20

1,4 mb screenshot about AV2

only gudea font

better compound prediction, better delta, + tx parttiuon mlr non intra non directional (disabled) vvc on in like only single left boundary ORIP IST ONLY ON THE LOW FREQUENCY WE CAPTURE MORE DIRECTIONARLY BUT MANTAINING SEE VVC INSTALL VQPROBE CREATE A PROJECT (FOR EACH STREAM) FOR AI SCENARIO FOR RA SCENARIO?

people can read article on their own

yes

do you think there is a lot of news

or that AV3 will succeed

probably that bother you, to me bothers that image contains big font and few information

For me no images = no comparison. I don't trust metrics at all. *(Dark Shikari intensifies)*

Fabian — Oggi alle 20:58 http://repository.essex.ac.uk/27250/1/adaptive_precoding_accepted.pdf https://discovery.ucl.ac.uk/id/eprint/10113692/1/115100C.pdf https://docplayer.net/164911616-Deep-neural-network-based-frame-reconstruction-for-optimized-video-coding-an-av2-approach-dandan-ding-hangzhou-normal-university.html who is that person https://wp.ufpel.edu.br/dpvsa/chia-yang-tsai/ 4th DPVSA gcorrea Chia-Yang Tsai don't watch Thor, the text written is silly, too less A lot of YouTube content is not great quality at source; content may be shaky, poorly processed, or repeatedly re-uploaded. Such content may not look perceptively better above 480p. 5: Big Buck Bunny is traumatizing video developers everywhere twitch not working for me https://boardgamestips.com/faq/which-is-better-720p-or-720p-x265/ copied by google good resource

the third link is basically the pdf i'm uploading now

nek i don't care about bandwidth

https://www.reddit.com/r/AV1/comments/e2lee3/looks_like_facebook_started_with_the_av1_adoption

Fabian — Oggi alle 21:11 At only 49KB, AVIF offers an exceptional result for the image used. WebP in turn offers much better compression than the venerable JPG. The results may differ depending on the original picture, but the potential save in picture sizes can help load websites much faster without sacrificing compatibility in most cases. But as noted above, there are situations where AVIF still cannot be used, such as uploading images through plugins where you cannot add alternatives and you are forced to use WebP or JPG. https://www.inoveo.ro/dezvoltare-website/cum-sa-folosesti-noile-formate-de-imagini-pentru-web/ if you want to watch comparison and have time

<:frogstudy:872914282772299796>

I agree.

https://www.youtube.com/watch?v=xiBNxcM4538&t=22s

Depending on the application-specific frequency of random access points, the experimental results show averaged bit-rate savings of about 10–15% for AV1 and 36–37% for the VVC reference encoder implementation (VTM), both relative to the HEVC reference encoder implementation (HM) and by using a test set of video sequences with different characteristics regarding content and resolution. A direct comparison between VTM and AV1 reveals averaged bit-rate savings of about 25–29% for VTM, while the averaged encoding and decoding run times of VTM relative to those of AV1 are around 300% and 270%, respectively.

so av2 is 23%

https://spin-digital.com/tech-blog/8k-vvc-encoding-and-playback/

VVC is going to be the same patent mess as HEVC, I don't really care too much about how it performs because it will only be a usable codec in 2040.

(or later, if they also patent encoder techniques in the coming years)

For the Web, maybe, but for TV and most likely smartphones and as a standard for physical media I think all companies will stay with MPEG formats as it was before

Yes, that seems likely, but even there av1/av2 might at some point become more attractive than figuring out who to pay and risking that more has to be paid when the hardware investments are already made.

avif is enable by default now in firefox: https://www.reddit.com/r/AV1/comments/oz5dul/firefox_92_has_fixed_avif_colour_space_support/?utm_medium=android_app&utm_source=share

Sad

No, it's progress. But now jxl too, please!

animation still doesn't work and they are enabling it...

Oh. That's annoying.

leaving a comment to that effect

this is super annoying

from a discussion in av1: what if animated avif had a separate mime type?

That's how it was 3 years ago, there was image/avif and image/avifs.

Then they decided to drop image/avifs and use the same media type for both.

oh what could've been 😔

https://css-ig.net/benchmark/png-lossless

all PNG are 8 bits/sample — or 1, 2, 4, 8 bits/pixels for paletted

machine: Intel(R) Xeon(R) CPU E5-2667 v3 @ 3.20GHz — 12,0 Go RAM — Windows 10

🤔 <https://www.reddit.com/r/compression/comments/ozup3w/weird_facebook_compression_artifacts_in_memes/>

? https://github.com/mozilla/mozjpeg/issues/328

Yeah and looks like it's still not fixed

interesting artifact

Looks like a bug in the decoder-clamping based deringing mozjpeg has for black and white hard edges

(a trick we are not exploiting yet in cjxl btw)

...any idea why?

I think in purpose not to make it more complicated and not to increase the number of MIME types

Probably that, and also the anticipation that anything that decodes one av1 frame can also decode more than one.

The more surprising thing to me was that originally avif was av1 intra only, and then they changed it to allow full av1 bitstreams

Why even differentiate then? Just use the same MIME for video and image.

And also animated WebP and PNG did not use other extensions and types, and for example GIF is just a separate format and not an indication of the animation Splitting video and images I think makes sense, animated images are always looped and without sound and it's usually something lighter than video

It's a different container though, and avif cannot contain an audio track.

Then Firefox should support all avif files <:whatisthis:853506460679405588>

Indeed.

Also they are usually different formats, for example a decoder that can decode AV1 cannot necessarily decode AVIF, just like a decoder for VP8 cannot decode WebP (even considering it is based on it)

avif also supports rgb, and is lossless avif just lossless av1 or some different format entirely? (not that lossless avif is good)

No, unlike WebP, lossless AVIF is not another format (which is why it is not as efficient)

i see

I got this bug on sending text images / screenshots on whatsapp too.

https://globalcompetition.compression.ru/#leaderboards

https://www.gdcc.tech

Compression ratio/Decompression time depends on libjxl implementation or jpeg-xl algorithms?

They didn't test best compression? Default speed is best they tried

Because at GDC the encoding/decoding speed had certain limits, in addition Jpeg XL and other open formats were only as a reference for comparison

Sad that in 2021 at GDC they don't compare the usual images, but something like this:

Not sure if JXL can encode this kind of data without changing the encoder (as far as I understand it's a mix of data and images)

I'd be interested in having even more efficient codecs to compare, good thing this time it's not just photographic images, but now it's a pretty niche data set

IIRC anything that you can fit in a 3d array you can compress with jxl lossless

well, up to some limits in the size of that 3d array, and one dimension doesn't get as good prediction as the others, but...

Jxl can encode 2D n-channel data in those data types, but "content may lack precise matching" is a bit of a problem - you need to feed the encoder an image, not raw bytes that may be too much or too little to fit an image

If you include animation, it's a 4d array where one dimension (the channels) is limited to 4k.

right... and the time dimension is also a bit weird 😛