JPEG XL

Context: https://discord.com/channels/587033243702788123/677266163994198020/925852795788214284

yep

https://twitter.com/richgel999/status/1476325003662667777

Also in the future it may be worth trying a fast JXL-GPU encoder using GPU-friendly methods

https://twitter.com/richgel999/status/1476623312658776066

Followed him on Twitter

https://twitter.com/richgel999/status/1476710105047576576

🤔 https://github.com/lvandeve/lodepng/issues/155

Fast paths for encoding/decoding would be interesting, also maybe it could be done even more efficiently than in fpng And on the one hand it would be more useful to promote and make something like this based on new formats (considering that Lode is also a JXL dev), but on the other hand - PNG is still the most popular and common format

why would lodepng, a png encoder/decoder, integrate a different png encoder/decoder?

lodepng description: > PNG encoder and decoder in C and C++, without dependencies

maybe they could add a fast decoding path for fpng-produced files since there's that ancillary chunk as the submitter of that issue stated

Yep, just pure fpng integration is not very good, but using similar fast path methods would make sense

it doesn't sound like that's what they're asking for <:Thonk:805904896879493180>

next someone will ask lodepng to support qoi <:kekw:808717074305122316>

https://twitter.com/richgel999/status/1478036725687541765

fair, the issue is a little unclear. i guess he's referring to fpng the "format," not the library?

Except that Lode will need to spend time on this implementation in the old format instead of improving and working on JXL

there's already been work done on detecting fjxl-produced files and using a faster decode path, right?

Yep, Luca and Jon do this in their spare time

<:Stonks:806137886726553651>

chad shit

what is fpng, is it a backward compatible png extension?

how does it work, does it just encode the idat in LZ4 instead of Zlib or something as an ancillary chunk?

Encoding - yes <https://github.com/richgel999/fpng> ```The files written by fpng conform to the PNG standard, are readable using any PNG decoder, and validate successfully using pngcheck. PNG files written using fpng can also be read using fpng significantly faster than other PNG libraries, due to its explicit use of Length-Limited Prefix Codes and an optimized decoder that exploits the properties of these codes```

> Also, the code has only been tested with `-fno-strict-aliasing`

<:Madge:859968580996956200>

ahhhhh, aliasing rules

one of the most abused language rules ever

FLAC uses linear prediction + Golomb-coded residual, it's an algorithm optimized for audio data yet simple enough that it decodes very fast. I wonder how Zlib or ZStandard would perform as a coder for the residual bitstream of FLAC since it can be quite stochastic due to the nature of linear prediction.

yeah sure i know what all that means <:kekw:808717074305122316>

basically flac for audio is kinda like png for images (does predictor magix, is combined with another compression thing ontop of that), and it'd be interesting to see how deflate or zstd would work to replace golomb thingy (kind of experiment like replacing deflate with zstd in png)

very interesting

I wonder what could be done with jxl-style MA context trees + hybriduint ANS

To put it simply, LZ-like coders probably won't bring much improvement for FLAC over Golomb coding because it's very hard to isolate repetition in audio. You'd essentially just be using the entropy coding part of Zlib or ZStandard.

Something like the weighted predictor of jxl might work well in audio too then...

sooooo... I wrote a fast PNG encoder on the same lines as fjxl

depending on image size and a few other things, 180~800MP/s on a single core

Faster than FPNG? And what about compression?

faster than FPNG: yes, if you disable adaptive predictor choices, otherwise who knows

it seems to be, but not by a lot

compression: ehhhh... I didn't test it too much

atm it only supports RGB8, but extending it to (G|GA|RGB|RGBA)(8|16) should be reasonably trivial

Considering that FPNG used a lot of different tricks and fast Adler/CRC32 implementations and other things, as far as I understand

so with fixed predictor I'd say it's anywhere from 2x to 4x faster than fpng, but compression suffers a bit

like, 10% or so

(depending on the predictor)

even ~1% if you use paeth

Is it fully PNG compatible or in FPNG implementation just haven't really tried other predictors?

it produces PNGs

as in, Chrome/eog/imagemagick open them

FPNG doesn't try other predictors AFAIU

http://www.libpng.org/pub/png/apps/pngcheck.html

it's 100% PNG spec compliant

i.e. I wrote it while reading the PNG spec 😉

(and the deflate/zlib specs...)

Very cool then, except that having a fast decoder for such PNGs would also be nice (because for those who need such speeds, decoders are probably even more important)

It's interesting that really fast decode is harder than really fast encode

Considering that codecs tend to be designed asymmetrically for fast decode and not necessarily as fast encode

well, really fast huffman 😉

ANS/AC are more symmetrical in that part, I suppose

in the end, fpnge and fjxl get a 3x speedup from basically the same trick - a very fancy Huffman encoder for some special cases 😉

But still, predict is easier to simd than unpredict, and thread parallelism is easier to do in encode than in decode

not so sure about parallelism

but otherwise yes

At least in png you need custom chunks to get parallel decode, while parallel encode can be done within regular png

I mean, modulo having offsets

Is parallelism in PNG encoding not quite standard, or just not all decoders can accept it?

you can produce 100% spec-compliant PNGs with parallel encoding

Encode side you can do things in parallel and concatenate bitstreams

Decode side you don't know without decoding (or having offsets stored somewhere) where rows start

Fundamentally, an encoder has all information from the beginning, while a decoder has to reconstruct everything as it is decoding

So, for own encoded PNGs it's not a problem 🤔 (if the decoder knows how they were encoded)

or if you write a specific chunk to give you that extra info

Also <https://github.com/w3c/PNG-spec/issues/54> <https://github.com/w3c/PNG-spec/issues/60>

https://twitter.com/richgel999/status/1478846234446209029

However, if the decoder is fast enough, a specialized one will not be as necessary https://twitter.com/richgel999/status/1478878192307945473

rust's decoder is pretty fast too

It's weird, but rust-png is not enabled for me or I'm doing something wrong and also maybe this benchmark does not work properly in Windows, very often spng and wuffs have the same timings <https://github.com/veluca93/spngt> ```libpng: 31243 usec spng: 15623 usec stb_image: 31248 usec lodepng: 46871 usec wuffs: 15622 usec```

Also maybe it would be easier to optimize some things in lodepng (CRC-32, Huffman, etc) or is it quite time consuming and dangerous to add new bugs/vulnerabilities? And in the future add fast modes

for rust: it only works with external modules, you need to pass an env variable and compile the crate separately

no idea about windows, dlopen exists I think so it should work but IDK how

` const char *external_lib = getenv("EXTERNAL_LIB");`

so you should do something like EXTERNAL_LIB=path_to_stuff.dll

https://www.contentful.com/blog/2021/11/29/load-avif-webp-using-html/

But, also a strange comparison only by the resulting size after encoding

https://www.reddit.com/r/AV1/comments/ry8qvg/intel_completely_disables_avx512_on_alder_lake/

So they'll have dedicated hardware av1 decode on those chips and also general-purpose 512-bit simd (which can e.g. be used to make software jxl encode/decode faster), but the 512-bit simd will be disabled (even though it takes up quite some of the die area), presumably to have a better sales pitch for their more expensive products...

Basically we're evolving from "general purpose computers" to more and more of a bifurcation between ubiquitous "consumer grade computers" (which is good to decode/consume; extreme examples being the iOS devices with their walled gardens of Apple-approved consumables) and more expensive "professional/enterprise computers" that have actual general-purpose computing power.

Maybe I'm a bit too pessimistic but that's what I feel we're moving to. At some point the consumer grade computers will stop being general-purpose computers but they'll only run "approved" software and have DRM built in — and it will be in the name of security (malware prevention etc) and stopping child porn, of course.

AVX-512 on consumer devices was never really viable because it reduced clock speeds to account for thermals & power draw, and made everything else slower

also iirc ander lake stuff involves mixing with power-efficient cores which can't do AVX-512 at all

it's also kinda annoyingly fragmented (with some CPUs supporting some of subset of AVX-512, and others supporting other), and was never supported by AMD cpus, so I'd say good ridance

I think Intel just rushed to push out the new generation CPUs to get their market share back, but they didn't have time to do something to make it convenient to use AVX-512 only on part of the cores, since they are not available on E-cores However, for ML, compression and many codecs the AVX-512 would be very useful https://twitter.com/richgel999/status/1479281825084284932

Well don't use it for memcpy if that's all you're going to use it for

So Linus prefers to get more cores instead of wider simd. I think both are useful.

I think he has a point that for typical applications, more/faster cores is more useful than wider simd.

But as libjxl shows, simd is really not just for HPC and AI applications

Anything related to images or video can benefit from simd

(and from more cores too)

I like the direction ARM/RISC-V are going with variable length vectors, instead of having a separate SIMD instructions for each length, though I will admit to having no idea how effective that'd be in practise for most apps

> Supported targets: scalar, S-SSE3, SSE4, AVX2, AVX-512, AVX3_DL (~Icelake, requires opt-in by defining HWY_WANT_AVX3_DL), NEON (ARMv7 and v8), SVE, WASM SIMD.

No idea why AVX1 is not a target

because there's a lot of stuff that is useful but doesn't exist for AVX1 - in particular many many integer and shuffle ops

For jxl we don't really need the integer and shuffle ops, or do we?

The FMA introduced in AVX2 is very useful though, I imagine

<https://github.com/libjxl/libjxl/commit/f413c429cfd5f2e1f65b5ebfc0c969b67ddbcbaf> Also, what about adding fpnge to the fast_lossless utility, like if the output image is png, then it's a job for the fpng encoder or is it not ready yet?

fast_lossless doesn't decompress 😛

Yes, I mean this (same as fjxl, but for png and in the same fast_lossless_main.cc tool) https://discord.com/channels/794206087879852103/805176455658733570/928395898638172251

ah, I'm making a separate repository

saying it's in the scope of libjxl is a bit of a stretch

I think it's convenient to have a universal tool for fast encoding, but with different files/headers for png/jxl, something like: ``` fjxl.cc fjxl.h fpng.cc fpng.h fast_lossless_main.cc``` And encode depending on the output image extension, like: `fast_lossless image.png image.jxl` (fjxl) `fast_lossless image.png image.png` (fpng)

ah, mayyybe

<@!111445179587624960> want to try it out? https://github.com/veluca93/fpnge

Yep

I don't expect it will do super well

you can `-DFPNGE_FIXED_PREDICTOR=[1 to 4]` to get the Very Fast versions

Anyway I can not compare the speed accurately, I think this needs a comparison from Jon, because I'm not a coder and can not create a tool and the same conditions for different codecs to avoid the impact of writing/reading from disk, PNG decoding time, etc.

<@!179701849576833024> 🤔 `Assertion failed: length >= 8, file ../fpnge.cc, line 369`

This happens quite often

uh

could be, didn't test it super well

can you link me a failing image?

.

should be fixed 🙂

https://twitter.com/richgel999/status/1481039953828233225

https://twitter.com/richgel999/status/1481040512383660039

added support for RGBA input too, while I was at it

not exactly well tested

> Never try predictor 0 It is also useless for this fast implementation?

yeah it's very bad always

TOP is nearly as fast to compute and compresses loads better

I mean, if you do proper lz77 then 0 *can* be useful

Looks like the fpnge has been spotted <:PeepoDiamondSword:805394101340078092> https://twitter.com/richgel999/status/1481043266728603651

Hmm...this page doesn’t exist. Try searching for something else.

It seems that the post was deleted, it was about encoders that will soon compete with FPNG, so some comparisons have not yet been shown

hehe

I've been chatting with Richard anyway, I think he'll write something soonish

Also, are the predictors selected by brute force, or is there some sort of heuristic? Because it's likely that some will be efficient very often and others very rarely

in fpnge?

by default, try all 4 and pick the best

if you compile with FIXED_PREDICTOR, well

Yes, for example, if I am not mistaken, fpng always uses filter/predictor 2 (most likely because it proved to be more efficient for the tested images)

yup

also because 4 may be better but it's more annoying to compute

Maybe also add Wuffs decoder support to FJXL/FPNGE, because decoding can take significant time and probably even more than encoding? However, as far as I remember, it needs some gigantic C source file, and I don't know how much that would affect the overall encoder binary size https://twitter.com/richgel999/status/1481027198530248714

meh

proof of concept, not serious production thingy

also, if you use it by reading from a PNG, you're using it wrong xD

I see, also as far as I understand, the main speedup of fast decoders comes from better optimized CRC-32/Adler-32 and Deflate implementations

also filters/predictors and pixel format conversions

but I'd bet most of it is deflate

does <#805176455658733570> cover audio codecs too?

why not

anybody heard of "SSDPCM"?

someone from the demoscene came up with this codec

turns out it basically boils down to DPCM split into short blocks, where deltas are vector-quantized and each block has a tiny codebook

it's meant for like 1bpp and 2bpp so I really mean tiny

and it turns out it's a surprisingly good codec

i made up an implementation of it in C, I'm kinda ashamed to share it but I did encode some stuff in it some time ago...

uhhh the author never released a toolkit for it

i did figure it out on my own and made the most basic brute-force encoder

know what, guess I'll just throw the code out here

I can't remember if I ever made a makefile for this but you just gotta `gcc -O2 ssdpcm.c` and it should work

don't judge, it's old hackish code, it just works

sample output at 1 bit per sample:

(this is from an older version where I did assymetric deltas, I gave up on it and it encodes an order of magnitude faster because it's basically a brute force search over the codebook lol)

1 bit vs. 2 bit comparison at the same sample rate

here are the raw bitstreams for those two in case someone wants to mess with those... it's a completely custom format I made for testing the codec

I don't, I deleted my GitHub account quite some time ago

nope nope

none of those

I do have a local git repo for it but that's it lol

I really couldn't care less, this was a prototype I did once, messed with it a while later and never touched it later

I thereby release it as public domain, really

it was not even my invention, just my implementation of it based on what I could guess it was

the original author actually did some more advanced stuff on the encoding side with shotgun hill-climbing instead of the greedy DPCM encoding + brute force codebooks I did

the original author is known as "Algorithm" in the scene

not at all

it's closer to SNES audio than it is to that

you know DPCM? where you encode each sample as the difference between the last sample and the current one?

🤔 https://youtu.be/OPBoAQMDoVs?t=11

yuuup that's it, I couldn't find the channel for some reason

I basically reverse-engineered their codec based on vague descriptions collected from pouet.net and youtube comments

it was originally meant to run on low-end hardware

there's a very impressive demo of it running on an Amiga, it's basically a 800K floppy demo that plays a full rendition of some theme song from Rocky and it sounds amazing for what it is

basically, it was a common thing to encode lossy DPCM using a fixed table of possible difference values between the last sample and the current one...

but Algorithm thought "what if instead of fixed values we divided our stream into blocks and we had a list of values for every block of samples"

and somehow this sounds better than ADPCM which is technically more advanced than this and is still used today in modern audio codecs such as apt-X, with the tradeoff that it takes way more computational power to encode than it does to decode because it relies on vector quantization after all

(btw, if you didn't know about it, apt-X, the fancy proprietary codec used in Bluetooth audio, is basically just ADPCM applied over 4 sub-bands with fixed bit allocation...)

I can easily ELI5 PCM vs. DPCM, but DSM takes a whole another level of understanding

Anyway: in PCM, you have a set of numbers representing different amplitude levels of a sound pressure wave... I'd guess you do understand that, right <@456226577798135808>

So, in DPCM, instead of storing the instant amplitude level of the waveform, you store the difference between the waveform itself and its last value, it's as simple as that, but the real deal comes when you wanna do lossy DPCM compression

You see, in lossy PCM, you basically have to take bits away so you have less possible positions for the sound pressure wave, and you get quantization noise

But in lossy DPCM, depending on your content, the difference between the current value and the next one might usually be a small number

So, if you allocate more possible values to small differences between the next sample and the previous one, and reserve the last few values for those moments where the difference between the next sample and the previous one is large, you'll tend to get better quality audio on average

This is the basic principle behind DPCM

But in reality it doesn't work that well, you either get lots of noise during loud high-frequency-laden passages, or you get an effect known as slope overload where the DPCM-encoded waveform can't keep up with the original waveform, it's a tradeoff as to how you allocate the possible difference values between the last sample and the previous one

ADPCM improves on DPCM by automagically predicting when "slope overload" occurs and scaling the difference values around to compensate for it... the same prediction algorithm is applied both during encoding and decoding to generate a reproducible audio stream... and most ADPCM codecs are able to get away with linear quantization (meaning each difference value is linearly spaced and scaled by the predicted scale value)... it automatically minimizes noise in both quiet and loud passages

uwu I'm happy I was able to teach you this

>python script by Kagamiin~ Waaaait, I did do that too lol, I published it on pret (a discord server related to researching stuff about Pokémon games)

it's a script to encode 1-bit PCM audio for using in Pokémon Yellow to replace Pikachu's voice samples

Really simple stuff, it just converts 8-bit PCM to 1-bit MSB-first PCM

(and it skips over WAV headers for convenience lol)

wtf there's like a serious bug in this, how does this even work?

wait does this work because of Python's bigint support?

wtf I'm friggin' flattered over my terrible code from the past... I swear it has to be older than a year... really?

so, I did `while all(x for x in samples):`, fair enough

then I did `for s in samples:` wtf this is going to consume every single byte of the file, it doesn't make sense

I should stop looking at my old code

and maybe make a brand new GitHub account?

I do have reasons to not own a Github account... but I do also have reasons to make a new one, oh well idk I'll just make one when I feel like it so I can make a pull request for this broken code of mine, I swear I tested this at the time and it did work?

I'd better go sleep... damn

oh wait nevermind, I reread it and this code actually should work lol

I was just misunderstanding Python's iterators and forgetting to read the line of code just above it

I'm really rusty in Python

I had to delete my old GitHub account because of reasons I shall not disclose, and I've been waiting for my trace to die off so that I don't get caught up on GitHub's TOS which prohibits one from owning more than one account

Mostly C, some Python, and quite a bit of shell scripting, I can also do Java but I'm not great at it, done some Groovy too... NASM is an assembler and not a language, you gotta learn to program for whatever processor you want to start with and whatever hardware or system features it offers

gtg

when i tried to make a second account it was instantly blocked

bye

probably ip

Fingerprinting

Basically multiple sources

Including IP address, cookies, third-party cookies shared around, also device ID (which usually makes up most of one's fingerprint)

lol GitHub mostly works without Javascript at least for browsing code

meanwhile Gitlab doesn't even render without Javascript

it sounds ironic but it's a fact

true

anyway I should sleep so bye

https://twitter.com/richgel999/status/1481376407968272385

There's also Mango, with sources, but which are kind of "hidden", so it's probably considered proprietary, but I still don't understand how it can have this speed or is it cheating with a single-threaded vs multithreaded comparison?

is that a PNG en/decoder?

Yep, PNG/JPEG/...

I have strong doubts you can get that speed with a single thread

https://www.liimatta.org/mango/

it does support multithreading

so I assume it uses it to get those numbers 😉

if you craft your PNG properly (or if you're encoding), I'm sure with MT en/decoding you'll be only limited by memory bandwidth

Yes, iirc it does require the png to have a certain structure to get those decode numbers, if this is the png implementation I think it is

<:Thonk:805904896879493180> https://twitter.com/richgel999/status/1483127512259608576

PNG and JPEG were both quite nice for their time, imo.

PNG did some things very right imo: - chunks that can be parsed (skipped) and partially understood even if you don't understand them - the 'modular' approach of separating the filters (predictors) from the compression (deflate), so in principle new filters and new compression methods could have been proposed to improve things - supporting high bit depth (16-bit!) at a time when most people still couldn't even see more than rgb565 on their screen

unfortunately the thing with 'extensible' chunks and compression methods etc is that it doesn't really work for anything non-optional — once you have a critical mass of decoders deployed, you cannot really produce new kinds of bitstreams that they don't decode

which is why we don't have JPEG-with-an-alpha-channel (technically perfectly possible, JPEG can encode 4 channels just fine), and no PNG-with-something-better-than-deflate

Some new discussions about JXL, FLIF, WebP2, etc <https://encode.su/threads/3520-WebP-2-experimental-successor-of-the-WebP-image-format/page3>

And also about the Jpeg XL speed, my pretty old builds are faster most likely because they did not have compression improvements for the slowest modes, I do not think that any compiler options can have that much effect

<:Thonk:805904896879493180>

`FLIF is quite poor, and it seems the lossless mode for JPEG-XL is nothing to write home about either.` `So hopefully WebP 2 turns out to actually be much better than FLIF and JPEG-XL at lossless compression.`

are they only comparing encoding speed? i dont get what they are comparing

Encoding speed and compression, but the comparison is still quite strange, because tested only one image and does not take into account that the speed of decoding is also very important, so that symmetric codecs are also not suitable, even if the encoding speed is like 5-10 seconds, waiting for 5-10 seconds to decode the image for viewing is not acceptable, and the faster symmetric encoder/decoder can not get that much better compression

Multithreading can speed up decoding, but Jpeg XL also uses it and splits the image into tiles/groups

I like the fact that he doesn't give us an image for us to test out his fact.

It's one big image in the posts above

https://cdn.discordapp.com/attachments/399068055092723712/928065449722282005/Doom_Eternal_Screenshot_2021.07.26_-_12.14.04.24.png

I can make a super fast and super dense codec for that image.

😜

Making a codec for a single image is trivial :)

Hardcode the image, define that image to be represented by 1 byte, store any other image uncompressed.

When evaluating codecs, it's essential to do it on a corpus that is representative of the images you actually want to compress. Testing on a single image is as silly as testing on all possible random images, for which (due to the pigeonhole principle) no codec can do better than uncompressed.

I like how optimizers made that huge PNG like 30MB smaller XD

Why use that 1 byte? Define the image to be represented by *0 bytes*, store any other image uncompressed! I've just saved you 1 byte 😄

Wait, that sounds familiar! I wonder where I've seen it before... <:Thonk:805904896879493180> ||~~LenPEG 2~~||

infinity% improvement <:Poggers:805392625934663710>

For web pages, similar to how browsers support Brotli

> **mpais** > Slicing/tiling in squares is also very much an artefact of thinking of lossless compression from the point of view of the techniques used for lossy compression. > For lossy compression you'll almost always want to use a transform for dimensionality reduction (DCT, DWT/WPD, SVD, etc), and using it on the whole image at once is usually bad for performance. > For lossless compression you get really good results from simple LPC (on most natural images), so for better performance you can simply split the image into horizontal slices, each the full width. > That gives you better cache locality and is usually mostly irrelevant in terms of compression ratio change. You can think of the filtering (not the actual DEFLATE compression stage) in PNG as an extreme case of this, where each line is a slice. <https://encode.su/threads/3520-WebP-2-experimental-successor-of-the-WebP-image-format?p=72737&viewfull=1#post72737> I also wonder if square tiles are really something not efficient and bad for lossless compression or do they still have benefits and this solution is pretty practical?

I think that'd just be on the encoder, if it breaks the image into tiles before encoding it, then each "encoding unit" is just operating on a contiguous memory chunk anyway

Can also do a multi step process, horizontal slices of the tile height, then break that slice into tile sized units before processing

Ah, The metagolfscript gambit

Slicing is a bit better for speed than tiling, and independent tiles have the compression downside of more poorly-predicted pixels (since it's the top row and left column of every tile that becomes poorly-predicted, not just those of the entire image)

But tiles have advantages over slices too: better 2D locality for compression (e.g. for local palette or for RLE), you can do ROI decode (only decode part of the image), can deal with very wide images, etc.

https://twitter.com/richgel999/status/1483746169629163524

Interesting experiments with lossy PNG

But, there are quite visible distortions on the edges https://twitter.com/richgel999/status/1483818811853783043

Yeah, that's true.

Any lossless codec can be used in a lossy way like that, I also did that in flif

lossy flif was just truncated progressive flif, right?

Not just that. You could also preprocess it to be more predictable, by chopping off lsbs of the predictor residuals

(and/or deadzoning low amplitude residuals to zero)

https://www.reddit.com/r/apple/comments/s5xcgd/why_is_heic_not_popular/

tbh it started getting relatively popular with pirating groups lately (anime or not)

heic?

nobody uses heic

HEVC? Yeah, that's fairly common. HEIC? No, only Apple devices put them out by default and nothing actually takes them as input.

Well I made heic encode/decode work on Cloudinary so maybe "nothing" is a bit exaggerated, but yes, outside the Apple ecosystem support is very poor, for good reasons (it's a patent minefield)

The way Apple uses heic seems to be using hardware encode in 512x512 tiles that are independently coded (to the point of having independent h265 codestreams in the heif file, which are then assembled using the `grid` construct of heif)

While file sizes are small, the perceptual quality is also lower than if you configure it to encode to jpeg

(and or course it gets even worse if you have to transcode the heic to jpeg to be able to share it)

I haven't seen an online service other than cloudinary that actually takes HEIC. All my assignments ban using HEIC by name because the professors can't open them.

I am assuming they calibrated their encode settings using a bad metric like psnr, which h265 can optimize very well for but that doesn't mean it actually looks good

Anyway, besides the technical issues, the main thing is that it's very much patent-encumbered, which is a clear no-go if you want an interoperable image format

I'm fairly certain if I started using exotic formats I could expand the list given the amount of tech savvy some professors have

Use JXL <:YEP:808828808127971399>

I don't know what Apple was thinking when they started using heic - maybe they were hoping for (even) more vendor lock-in by using a format they know other platforms are not going to support

Another thing is probably to get the most mileage out of their custom silicon with a HEVC encoder

With WDP (JPEG XR), I think Microsoft genuinely just wanted to have an HDR-ready image format, and they standardized it and made sure it was not patent encumbered. But that codec has the problem of being very "meh" in compression (it positions itself as somewhere between JPEG and JPEG 2000 in terms of complexity and compression results), and the only public implementation is abandonware...

Yes, that could also be the case. "We have this shiny hardware, now let's use it!". I think a similar reasoning is pushing avif btw.

>student has turned in, let's see it >File won't open in photo viewer >Don't give student grades (In the future) I WILL NOT accept. .jxl .avif .flif .HEIC .DDS .qoi .bpg or .JP2000 files.

Nvidia switched from EXR to JPEG XR for HDR screenshots on Windows within the last year or so

The default picture viewer in Windows doesn't do any form of tone mapping, but I suppose that's better than something most people couldn't open

I need to make a 10-bit version of fjxl, it would be great for making HDR screenshots...

I've got a process for converting Xbox HDR screenshots to JXL, lots of sharp edges that make it annoying

The MS JXR decoder has limited output support, it says it can emit the 10 bit values to TIF/BMP, but then nothing I've found supports reading those files properly

iirc GIMP encounters an error trying to load the TIF files, while ImageMagick sees it as pure noise, while they treat the BMP file as 8bit

The JXR tooling is a mess, finding input/output formats that actually work is very tricky with it

I dunno if 10-bit TIF is well-standardized, I suppose the main question is if you pad with msb zeroes or with bogus lsb (either zeroes or convert more properly to 16-bit but ignore the 6 lsb). If applications do not agree on that, the result will be garbage

I assumed if neither ImageMagick or GIMP couldn't open it (Or any other app I tried) that it had to be a custom format that wasn't worth them supporting

The issues with BMP surprised me a bit, since it does actually have a properly specified way to pack >8bit values into a 32bit image

ImageMagick reports the image as being "8/16bit", but shows the individual channels as 8bit only

oh. yeah ive misread that

<:Poggers:805392625934663710> <https://github.com/veluca93/fpnge/commit/a1e8f5b7029716f6c73cc9846e9126da822d05b7>

So no forced RGB to RGBA conversion?

I feel a bit stalkered :P

Yup

Now I want to see if I can improve compression

I think I can at minimal speed impact

https://youtu.be/hmmIl9aMz4I

Good old memories

libpng-turbo :)

I can think of one reason.

It's money and being able to use HW encoders.

I guess it depends on whether their computer has the webp image extensions

Also, what makes FPNG have better compression even with one filter? And since there are some changes, maybe copy build.sh from FJXL as well (although I don't know if it's really necessary, but it's a kind of unification)

well, one reason is that their huffman tables are not completely horrible xD (fixing that...)

How does fpng do lz77? Probably in a less constrained way than fpnge, I'd guess?

likely

pretty sure iphones use it by default

Until you share it anywhere, then it gets transcoded to jpeg

Anywhere outside the apple ecosystem at least

<@!111445179587624960> I submitted the code to build better Huffman tables, if you want to give it a try... on my set of benchmark images it's a 5-20% improvement (depending on the image), with an average somewhere around 10%

Yep, it will be interesting to compare, 5-20% is pretty noticeable

probably on different corpora it's not as good

but still, should have some decent improvements

Also, how hard is it to make encoding multi-threaded? Then FPNGE would beat the other encoders with a big advantage (at least until something similar is added to FPNG)

I mean... with the speedup from today, I think I already am leaving fpng in the dust 😛

Yes, but it can still be many times faster if there are no needs to encode multiple files in parallel Btw, FPNG still has higher compression on some sets (of those that have already been encoded)

yeah I'm not surprised

the way I'm doing RLE is pretty barbaric (it heavily trades off density in favour of simplicity & speed) so fpng doing better in some cases is not a huge surprise

about multithreading: I'm not actually sure how much faster this could get even with MT, it's getting uncomfortably close to memory bandwidth xD

Even without fixed predictors?

no, that's a bit slower

but tbh the density gain from choosing predictors is very much in the "dimnishing returns" area

I rarely see more than 1-2%, and it doesn't *really* seem worth it

well, ok, except on screen content

Is it possible to fast identify such images and also is it possible to encode black and white and grayscale images more efficiently or for PNG as a format it doesn't really matter?

Maybe do something like a quick heuristic only for images where predictors can have a noticeable effect, or would that make the code too complicated?

I could do a few more tricks for images that are less than RGB888

I didn't bother trying yet 😛

identifying images where changing predictors would help... IDK

in interesting news, out of a few images I was trying out I found this interesting one: ``` luca@desktop ~/fpnge main $ FILE=/data/jpeg_xl_data/imagecompression.info.rgb8/spider_web.ppm.png; ~/fpng/bin/fpng_test $FILE && ./build.sh -DFPNGE_FIXED_PREDICTOR=4 && ./build/fpnge $FILE /tmp/fast.png 20 && compare -metric pae $FILE /tmp/fast.png null:; echo; ls -l /tmp/fast.png SSE 4.1 supported: 0 Filename: /data/jpeg_xl_data/imagecompression.info.rgb8/spider_web.ppm.png Dimensions: 4256x2848, Has Alpha: 0, Total Pixels: 12121088, bytes: 36363264 (34.678711 MB) ** Encoding: FPNG: 0.069215 secs, 14317733 bytes, 13.654 MB, 167.010 MP/sec lodepng: 5.287667 secs, 10890859 bytes, 10.386 MB, 2.186 MP/sec stbi: 1.788477 secs, 17305221 bytes, 16.504 MB, 6.463 MP/s qoi: 0.103213 secs, 14334346 bytes, 13.670 MB, 111.997 MP/sec ** Decoding: FPNG: 0.074284 secs, 155.613 MP/s lodepng: 0.265825 secs, 43.486 MP/s stbi: 0.195687 secs, 59.072 MP/s qoi: 0.091144 secs, 126.828 MP/s 398.386 MP/s 6.919 bits/pixel 0 (0) -rw-r--r-- 1 luca luca 10482891 Jan 23 00:17 /tmp/fast.png luca@desktop ~/fpnge main $ convert $FILE /tmp/x.ppm && convert /tmp/x.ppm /tmp/libpng.png && ls -l /tmp/libpng.png -rw-r--r-- 1 luca luca 10660099 Jan 23 00:17 /tmp/libpng.png ```

(where fpnge is faster *and* denser than anything else, including libpng/lodepng)

i think you can also configure the camera to save as jpeg in the first place

iphones use heic

but nobody uses heic

<:Thonk:805904896879493180>

a lot of people use iphones and don't change default settings

what i mean is that nobody actively works with heic

actively and knowingly

those people use images

some would call them jpegs

https://twitter.com/tunetheweb/status/1484819698592137217?t=VX5cgjNklwXa2tDQMQ5MDA&s=19

https://twitter.com/richgel999/status/1485878580898934785

<@!794205442175402004> Also, can this be useful for the JXL/FJXL palette or is it very different?

maybe

https://twitter.com/LucaVersari3/status/1485971553892323333 uploaded some slides with brief explanations of how fjxl & fpnge work

also, a few fancy plots 😛

Except that I would like to see `ECT -1`, instead of or in addition to OptiPNG, because it is more relevant and much faster and efficient, OptiPNG is pretty old <https://github.com/fhanau/Efficient-Compression-Tool>

ehhh Jon picked those 😛

Well, then maybe after some further improvements for the FJXL and new comparisons

that I can do

yup, they were for a presentation

but nope, no video

who's "we"? 😉

it should be easy to do so

Such an encoder still has a rather niche use to replace other popular encoders, although a similar fast mode in some of them would be useful Also, presentations to promote JXL or just some kind of research?

just me finding out that people were interested in how fjxl and fpnge work and being asked to give a presentation

and at that point, might as well publish the slides

it's not exactly *hard* to make a SSE4 or so version... but yes

I was too lazy to write it in a more portable way

But at least there is also FPNG https://twitter.com/richgel999/status/1485978449231683587

And its -s variant is also pretty comparable (on average), although slower, but even that speed is usually excessive for normal use and if not required to encode petabytes of images every day

And FPNG also has a very fast decoder for its own encoded images `FPNG: 0.000657 secs, 2378.959 MP/s` <:monkaMega:809252622900789269>

Almost lossless? 🤔 https://twitter.com/nikq/status/1485975181156057091

not sure what that's supposed to mean 😛

I guess that's with multithreading though

As far as I know FPNG does not support multithreading (yet), most likely some images are just good for RLE

that decoding speed seems too fast even for very good rle

could be wrong though

For some other images it's not that fast

ah that makes sense then

fpnge is interesting! They are currently dusting off and updating the PNG spec, one of the things that looks promising is the `mARK` chunk that allows parallel encoding and decoding (<https://github.com/w3c/PNG-spec/issues/60>).

I'm also thinking, what if FPNGE used a combination of, say, the two most efficient for different content predictors to get the speed a little slower than one fixed predictor, but the efficiency is closer as like if all were used or is it useless? 🤔

FPNGE tries all 4 unless you compile it in a special way

if you switch to PAETH only it's not much worse

Yes, I understand, but I meant to use only the 2 most useful instead of 4, or it would not much change the encoding speed?

Still, all 4 predictors on some images or sets give a significant advantage compared to only PAETH and I am thinking that maybe a duo of some predictors will work better, with a small speed loss, compared to only one

Yes, something like fpnge24 or 34 could be a good idea

Hmm, theoretically I can test it, if only I know exactly where in the code I can "remove unnecessary" predictors, I think it's somewhere here: <https://github.com/veluca93/fpnge/blob/main/fpnge.cc#L441>

here: https://github.com/veluca93/fpnge/blob/main/fpnge.cc#L708

just comment out any subset of those "trypredictor<x>" lines

well, as long as you leave at least 2 🙂

(only 1 is equivalent to using a fixed predictor)

According to preliminary tests, FPNGE34 does not differ much in speed from FPNGE4, but has better compression

how much better?

I will finish the spreadsheet for more accurate results

WTF is Gralic? I was on the compression subreddit and someone was recommending it for lossless archival purposes, and I've never heard of it before.

One of the closed/proprietary formats from Alex Rhatushnyak, but it is efficient only for photo images (also a similar predictor is used in JXL `-e 3`) http://qlic.altervista.org/LPCB.html

Also, it's the same guy who once invented a revolutionary format (but it was lossy, so it had such compression) and I also once answered in a similar thread <https://www.reddit.com/r/jpegxl/comments/mepoun/modern_lossless_jpegxl_still_defeated_by_old/>

And also EMMA is better than Gralic As a storage format they can be useful, but for other purposes very questionable because they have sometimes like 100-1000x slower decoding than Jpeg XL Although, I would be afraid to store anything valuable and crucial for archiving in closed, very little tested, experimental formats

I don't know what gralic does, but the weighted predictor of jxl was also made by Alex Rhatushnyak

Luca and me changed it a bit from Alex' original version, which had hardcoded parametrizations (3 variants for 8-bit, 1 for 16-bit) so we replaced that with signalled parameters, and the original also had an integer division per pixel (which is a crazy slow operation), which we replaced by something that can be implemented with a lookup instead.

Also the original WP had its own hardcoded context model, and we replaced that with MA trees, which is strictly more expressive.

(the original WP context model can be represented as a fixed MA tree that uses only the WGH property, which is what cjxl -e 3 does: it skips MA tree learning and just uses that fixed tree)

<https://www.reddit.com/r/compression/comments/scvzmf/question_im_here_as_an_ignorant_looking_for/>

I don't know what tests he has seen, but the mention of PSNR is a red flag...

PSNR correlates extremely poorly with subjective quality assessment

https://cloudinary.com/blog/detecting_the_psychovisual_impact_of_compression_related_artifacts_using_ssimulacra

ssimulacra is better than psnr but it's still far from perfect — I made it when jpeg, j2k, webp, jxr were the main codecs of interest, and it was tuned to correlate with subjective eval of those.

ssimulacra is quite forgiving for blurring artifacts, so I think it might be overestimating the perceptual quality of encoders that go heavy on the smoothing

Why is there a difference between `cwebp -lossless` and `cwebp -lossless -q 100`?

is there? maybe different default effort?

As far as I remember -m 6 and -q 100 used to activate the crunch mode, maybe it's something like that (but it was in older versions)

``` A:\>cwebp -lossless -z 9 -m 6 -q 100 g8d.png -o 100.webp Saving file '100.webp' File: g8d.png Dimension: 3840 x 2160 Output: 170476 bytes (0.16 bpp) Lossless-ARGB compressed size: 170476 bytes * Header size: 2302 bytes, image data size: 168148 * Lossless features used: PALETTE * Precision Bits: histogram=6 transform=4 cache=2 * Palette size: 247 A:\>cwebp -lossless -z 9 -m 6 g8d.png -o ll.webp Saving file 'll.webp' File: g8d.png Dimension: 3840 x 2160 Output: 824374 bytes (0.80 bpp) Lossless-ARGB compressed size: 824374 bytes * Header size: 14312 bytes, image data size: 810036 * Lossless features used: PREDICTION CROSS-COLOR-TRANSFORM SUBTRACT-GREEN * Precision Bits: histogram=6 transform=4 cache=7 * Palette size: 247 A:\>cwebp -version 1.2.2 ```

Yes, it's probably a crunch mode Also, since WebP was mentioned, does JXL use any palette reordering or sorting techniques for more efficient compression? For example as it has been used here in WebP from the beginning of this source code: <https://github.com/webmproject/libwebp/blob/master/src/enc/vp8l_enc.c> Maybe also use something fast for the FJXL palette mode?

Do you know how to use crunch mode with near lossless?

Perhaps it works in the same way, but maybe not at all

both fjxl and cjxl sort the palette on luma and then on alpha (not quite in the same way though, fjxl looks at the Y from YCbCr multiplied by A, cjxl sorts lexicographically on YCoCgA)

that's probably not optimal, but at least it's better than doing nothing

And also the modified Zeng method that was recently mentioned: <https://github.com/webmproject/libwebp/blob/master/src/enc/vp8l_enc.c#L152>

Perhaps it will also be useful to use Select predictor and some techniques from lossless WebP for palette images 🤔

ok, thx! I didn't made a difference between ll and nll in that case but it generally works that way.

Gralic for archiving is probably a very bad idea. I had to do some searching to find a "demo version", now installing wine so I can try to run the .exe

a closed-source, proprietary, experimental, non-standardized format is pretty much the opposite of what you want for long-term archival purposes

Yep, among such closed formats only BMF is relatively stable, at least it has a long history of existence and use and is more versatile for different content, not only for photos

And also about Gralic unbeatability: <https://www.reddit.com/r/jpegxl/comments/mepoun/modern_lossless_jpegxl_still_defeated_by_old/gtm8geq/>

well it does seem to get very dense results and at least on photos, jxl doesn't beat it in density

or at least not yet - perhaps with future encoder improvements we can beat it, we're still quite far from exhaustively making full use of the bitstream expressivity

on some photographic images, jxl _can_ already beat GraLIC, if you throw enough effort at it: ``` 9871305 ClassA_8bit_BIKE_2048x2560_8b_RGB.ppm.png 7590448 ClassA_8bit_BIKE_2048x2560_8b_RGB.ppm.png.jxl3 7168248 ClassA_8bit_BIKE_2048x2560_8b_RGB.ppm.png.jxl7 6909524 ClassA_8bit_BIKE_2048x2560_8b_RGB.ppm.png.jxl9 6187395 ClassA_8bit_BIKE_2048x2560_8b_RGB.ppm.png.jxl9E3g3 15728657 ClassA_8bit_BIKE_2048x2560_8b_RGB.ppm.png.ppm 6566562 ClassA_8bit_BIKE_2048x2560_8b_RGB.ppm.png.ppm.gra ```

for lossless I think there are three main actual use cases: - fast encoding during authoring workflows: it's not that density doesn't matter here, but speed matters more - you don't want to stare at a "saving..." progress bar every time you hit ctrl-S - archival: density matters, speed is less of an issue, but long-term reliability and interoperability is important: how likely is it that in the future, it will be possible to open the file? Standards are a must here. - web delivery for images that just don't benefit (enough) from lossy, e.g. logos etc: here encode speed typically doesn't matter much, decode speed and browser support do matter a lot

(and then of course there are niche use cases like medical, science, etc, where the requirements can be different)

Yes, but also another advantage of GraLIC is that it has quite fast encoding for such results (but it takes the same time to decode) Also this EMMA can be even denser, with some more encoding time, but still fast enough for these results https://globalcompetition.compression.ru/assets/files/compressors/EMMA.7z But, yes, they are suitable mostly for the theoretical storage use case (if imagining that encoders are very stable and safe)

I kind of wonder why Gralic and BMF are closed-source and don't just have a github repo — it doesn't look like the authors are planning to actually have commercial applications so they want to keep their secret techniques secret

it's obviously too late to change the jxl bitstream at this point, but if they have interesting encoder-side heuristics, some ideas might be transferable

Yes, BMF is almost 25 years old and it was not used for commercial purposes, it was just closed source, as well as in a recent discussion on encode.su, the EMMA author was not impressed with the JXL lossless results and said it was pretty easy to make something much more efficient and fast, but he also did not open the source code for his compressors (mostly because it is like bad code) But if such more efficient codecs were open-source, it would be easier to use and practically test their ideas

decoder being as slow as the encoder doesn't sound good in that respect though - smells like it's mostly a good predictor / ctx model / entropy coder that is complex and symmetric, and not so much an expressive bitstream with fast decode but search-intensive encode

not open sourcing an experimental encoder because it is bad code sounds silly to me - who cares about code quality of something experimental, just put a disclaimer on it that it's experimental

if you can share binaries and expect people to run them, you can also share code

if someone is claiming that it is pretty easy to make something much more efficient and fast for lossless compression, then I'd encourage them to submit their ideas as input to JPEG (WG1) so we can consider it for a potential extension of jxl, if there is really a low hanging fruit that we're missing.

that or just make a github repo

From fast encoders/decoders I found LEA the most interesting, moreover, as the author said, it is not optimized at all and is very easy to parallelize both encoding and decoding, by compression LEA can often be equal or better even to JXL -e 9, but with very high encoding speed, with some optimization theoretically comparable with JXL decoding speed https://globalcompetition.compression.ru/assets/files/compressors/LEA.7z

but just putting magic .exe files on the internet is not going to lead to any long-term progress

what is needed is at least a sufficiently detailed explanation of how the algorithms work — or even better, some code that can be studied

claims of "not optimized at all, can be much faster" are something can only really be demonstrated by actually doing it

Yes, one of the recent discussions was here, but similar ones were before, I think also such developers want to somehow monetize their knowledge, but perhaps this does not happen and the research results and ideas essentially just disappear into oblivion and the authors often switch to completely different fields <https://encode.su/threads/3520-WebP-2-experimental-successor-of-the-WebP-image-format/page3>

I mean if you want to monetize your expertise, and get a contract somewhere, then putting something on github is going to be more effective than distributing some .exe files in obscure russian forums 🙂

it's mostly just a pity that there might be great ideas hidden inside GraLIC, BMF, EMMA, LEA, etc — and they are likely to just going to have to be rediscovered by someone else

Except that some monetization is possible if winning GDCC and similar competitions, but this kind of monetization is not very stable

Yes, for example such quotes: > FLIF is quite poor, and it seems the lossless mode for JPEG-XL is nothing to write home about either. > To elaborate why, allow me to use my poorly written entry from the GDCC'20, "LEA". > It's about 700 loc (excluding the LZW code), written in an afternoon, single-threaded, doesn't use any SIMD, and since I was lazy I used my existing code for a planar image codec and didn't even bother converting it, i.e., it goes through the whole image 3 times, encoding a single color component in each pass. > Now, LEA is trivially parallelizable, so let's simulate what we'd get with a multi-threaded version, by splitting the image into 4 slices (2 by 2). In that case, compression actually improves, down to just 36,271,421 bytes. > And even accounting for obviously less than linear scaling, with 6 threads, decoding time would likely already be close to JPEG-XL at maximum effort (-e 9). > With proper optimization, it would likely be on par with it. > As for LEA, I have no doubts that either Shelwien or some of the other amazing coders in this forum could in less than 24h post a completely rewritten and much optimized version with proper multi-threading that beats even FLIC in terms of pareto-frontier. > I can't do it, I'm a lousy coder on my best day, but it seems quite possible, even if it wouldn't be suited as a proper codec because it isn't amenable to hardware implementations or such. > > I just feel that a next-gen lossless format should actually be, you know, next-gen. So if it provides options that put its decoding performance in the same ballpark as other codecs, it better at least consistently beat them on compression ratio.

> FLIF has its merits, but simply disregarding closed-source codecs, even if experimental, doesn't change the fact that better solutions exists.

this man sounds like a lunatic with 0 practical knowledge. "in less than 24h post a completely rewritten and much optimized version"

yea F\*\*\*\*\*\*\* Right

It sounds like it, but if I didn't know who it was, I wouldn't have paid attention, but this man has won a lot of compression competitions (where very experienced compression engineers have also participated) and contributed a lot of code to various compressors

It's a funny mix to trash talk like that and say everything else sucks, you made something better in just an afternoon, but then at the same time saying you're a lousy coder and you're too embarrassed to show your code.

For some game repacker they usually use LOLZ to compress texture, LOLZ also good for general image compress?

My god.

Someone measuring compression performance using PSNR <:whatisthis:672847617796997165>

No, but it has special methods for compressing textures

I understand, thank you 🙂

<:megareee:900504155632828457>

So many things wrong with that quote

One thing being that psnr is not lower-is-better but higher-is-better

Please help me.

https://old.reddit.com/r/compression/comments/scvzmf/question_im_here_as_an_ignorant_looking_for/huik5fh/

https://www.youtube.com/watch?v=CriuRH9q-hU

Measuring RGB values to determine quality?

It is strange to use only LZ4 on RAW image formats and consider it unbeatable, I think even something like FPNG will win easily, also having very high decoding speed (and for more modern formats this can be done even more efficiently)

Also about PSNR https://videoprocessing.ai/metrics/ways-of-cheating-on-popular-objective-metrics.html

Yes, a very smoothed, outdated, bad for tests image (I do not understand why this image is still used, not even considering some moral aspects) For both lossy and lossless, instead of getting a more varied set of more modern and higher quality images

Smoothed is a critical part of this to me since AVIF's first noticeable artifacts are usually smoothing out any fine details

However, as I said before, it would be interesting to use methods good for very fast decoding in JXL (even if the encoding is not that fast) and maybe have some kind of specialized fast decoder for this in the future, even though it is not very good for spreading a complete format, but still, it is a pretty demanding thing

Also for the sake of interest, while reading some blogs, does JXL use only rANS? Something from FSE/tANS is not very suitable for such cases or does it not give any benefits? <https://fgiesen.wordpress.com/2015/12/21/rans-in-practice/>

The entropy coding of jxl is MA context + configurable hybriduint (meaning a symbol gets split into an entropy coded token and some number of raw bits, depending on the token), optional lz77, and then either prefix (huffman) or ANS for the entropy-coded tokens (with a prefix code/ANS distribution that depends on the context)

Yes, I meant among the ANS family

We do use some kind of tabling (the AliasTable) in ANS, so I am not sure what to call it. <@179701849576833024> maybe we need to come up with a name for the specific flavor of ANS we use, and describe it somewhere

It is a rANS

With this fancy alias table trick that allows to use O(symbols) memory instead of O(state) at decode time

> Revolutionalredstone > > Here's a quick reference comparison: https://imgur.com/a/vBgZNp3 > > Definitely difficult to see any difference when viewed without zoom. > > I'm sure I won't need to mention how horrid a 24kb jpeg would look. > > I do think for such a grainy image a slightly higher setting would be good. > > Ta

I find that not visually lossless at all <:Thonk:805904896879493180>

It's smoothed out all the grain

Also how did an adult image become part of the standard testset?

Yes, because such comparisons are very subjective, some people like smoothness even more than the original About the test image, I think because the engineers were mostly young men 🤔

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

To explain Lenna's popularity, David C. Munson, editor-in-chief of IEEE Transactions on Image Processing, noted that it was a good test image because of its detail, flat regions, shading, and texture. However, he also noted that its popularity was largely because an image of an attractive woman appealed to the males in a male-dominated field.[10]

I assume it's mostly the latter

It's not a particularly good test image imo, since - it is a scan of a print - a scan from 1973 - only a narrow part of the color gamut is used - most of the image is noisy and out of focus - it's only a thumbnail by today's standards

And I also do not see anything magical for AVIF at these bitrates, for example 24kb JXL