JPEG XL

"quality level" and psnr are such meaningless things...

"faster loading times"? Can they accelerate time? 😜

Sure. Or "faster loading". I'm just making fun of it. 🙂

https://twitter.com/PascalMassimino/status/1400473040203436036

https://discord.com/channels/794206087879852103/805176455658733570/849787979698143282

As I predicted, video sites will use it.

Not sure how they got WebP faster than JPEG.

Default cwebp vs default mozjpeg?

Also avif only being 3x as slow is kind of suspect, must be a pretty fast encode setting

https://twitter.com/daemon404/status/1400474108987678723

And webp seems to be default > I also went and checked our code for reference, in lossy webp mode, we're using cfg.method == 4 in libwebp. `-m 4` (default)

Assumed so. Default mozjpeg is pretty slow - with some options it is still good and quite a bit faster

That fast aom setting is probably not much better than webp though

If you would use decent metrics or actual subjective evaluation, I mean

Recent libaom builds gave a significant increase in speed (but it's still not very fast)

I wonder what cpu-used setting they are using

https://miro.medium.com/max/2400/1*FeDdawlRhreqeJh1mVKytg.png

I see pretty ugly banding in all of those skies

Question is - is the JPEG the original and did they start with a banded image?

But, this is VMAF and since it is a video service, the sources for these previews will be encoded lossy video (which is usually not very good quality) So perhaps a very low bpp and AVIF for something like this is not such a bad solution

That too <:This:805404376658739230>

If they downscale the video for those thumbnails, it shouldn't be _that_ lossy

They start from full HD or 4K, and scale that down to what? Something quite a bit smaller I bet

I think the idea is that even if the original uploaded video was very high quality, the videos that are produced by the service are typically far lower quality and could have caused the banding prior to the thumbnails being generated.

Yes, but it's probably a similar marketing test as Netflix when trying to show the difference at maximum compression (and the one with less artifacts wins)

I feel Netflix compressed those images more than they needed to be.

I mostly see the block size of the banding getting larger from jpeg to webp to avif

It reminds me a bit of the days of High Color

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

It feels so wrong now that we finally have displays that are capable of pretty good color reproduction (and even HDR etc), that compression is quantizing colors and makes ugly 64x64 blocks of banding

Btw https://twitter.com/MikeTiVo/status/1400484825312727041

A test gallery with HDR JXL images would be interesting

just need to find the source images 😛

<@604964375924834314> do you have some you could release with a CC BY-SA license? Could add some to the conformance repo, and also add a page to jpegxl.info with a HDR test gallery

Can also make some HDR <#824000991891554375>, I still need to get me an HDR screen though, otherwise I cannot really see what I am doing.

fwiw, http://www.anyhere.com/gward/pixformat/tiffluvrend.html contains also some nice HDR rendered images in TIFF format (LogLuv encoding). This was the last image of that gallery (Pete Shirley's photopic RGBE picture of Snellen and Macbeth CC charts).

We can do better than RGBE though

RGBE is a bit of a hack imo

Wasn't JPEG XT based on the RGBE format? Yeah, it's a bit of hack

Well XT aims to be bw compatible, and for that RGBE is not so bad, if you put the tone mapped SDR image in RGB so it gracefully degrades to that

AAC 139 KBPS ABR AAC 240 KBPS VBR EXHALE 1.1.6 STABLE PRESET G -S -V 66.6817 -h - %d GXLAME

.....

.....

NERO ENCODER

FYI the hydrogenaudio wiki recommends FDK AAC over Nero: https://wiki.hydrogenaud.io/index.php?title=Advanced_Audio_Coding#Encoders_.2F_Decoders_.28Supported_Platforms.29

ffmpeg can be built with support for fdk although prebuilt binaries don’t have that because of license incompatibilities which prevent redistribution of such binaries

(ffmpeg’s `configure` script needs to be called with `--enable-libfdk-aac --enable-nonfree`)

then one can encode with: `ffmpeg -i input.flac -c:a libfdk_aac -vbr 5 output.m4a`

QAAC, FDK AAC, OPUS which is better?

OPUS or – if you need lossless – FLAC

right, the main advantage of AAC is probably compatibility

the Nintendo DSi can read it for example :p

ok, thank you 🙂

<@!461421345302118401> if you would like some data on the subject, there was this listening test: https://listening-test.coresv.net/results.htm

which found that around 100 kbps, Opus was better than Apple AAC which in turn was better than Vorbis which was similar to {MP3 with 30% more bits}

so qaac is rather decent too

Opus

The best AAC encoder now is generally considered CoreAAC (which is now on iTunes), but that was before the most modern xHE-AAC (USAC) profile and there is only one most complete and high-quality encoder from Fraunhofer, also xHE-AAC is better than Opus at very low bitrates and about the same as past AAC profiles at higher bitrates, but it has no backward compatibility

<@!604964375924834314> <@!263309374775230465> <@!111445179587624960> Thank you for your help 🙂

Imo, Bass sounds realistic on opus than fdk aac. (256kbps)

I think there are very few people who can hear the difference between AAC and Opus in blind tests at such bitrates, even at 128kbps it is difficult enough, unless using special complex songs

idk how special but on some complex tracks its indeed pretty noticeable, even on higher bitrates

http://abx.digitalfeed.net/opus.html

at home, I personally have little reason to use lossy audio anyway, in part because there’s also an archival aspect to it

and on-the-go, I’ll encode to whatever my portable player can play

(or, let’s say, what seems to be the best codec among those that it can)

which for my iPod Touch seems to be AAC

but if it changes, still having the lossless source means that it is possible to encode to a better codec without generation loss

so keeping lossiness to where it matters has advantages

reasonable approach. listening conditions not-at-home usually aren't ideal anyway

fwiw, libvips 8.11.0-rc1 is now available which should fix that.

The what's new post has some more details https://libvips.github.io/libvips/2021/06/04/What's-new-in-8.11.html

Are there any compiled Windows builds?

Just uploaded those to https://github.com/libvips/build-win64-mxe/releases/tag/v8.11.0-rc1

(you'll need the `-all` variant for PPM support)

Yep, PPM[strip] works, but JXL: *vips-dev-w64-all-8.11.0-rc1.zip* ```vips.exe copy 1.png 1.jxl VipsForeignSave: "1.jxl" is not a known file format```

Or it's not ready yet?

Oh 🤔 > JPEG-XL is still a little immature so it’s not enabled by default in libvips 8.11. Hopefully the missing features (metadata, progressive encode and decode, animation, etc.) will arrive soon, and the remaining bugs will be squeezed out.

*squeezed* out see what you did there

Hmm, for some PNGs the converted PPM is different for VIPS and IM (as well as encoded sizes after other encoders)

PPM sizes are the same, but inside they are different (and this also affects compression efficiency for some encoders)

Maybe a color conversion thing?

Maybe one of them just dumps the values, stripping the color profile, while the other one might be doing something else? (converting to sRGB first?)

Looks like vips flattens the transparency, whereas ImageMagick drops the alpha channel when saving to PPM. Reproducer: ```bash $ vips getpoint CQ2nhMO.png 0 0 120 82 41 230 $ vips ppmsave CQ2nhMO.png x.ppm --strip --vips-cache-trace vips cache : pngload filename="CQ2nhMO.png" out=((VipsImage*) 000001f7c4720020) flags=((VipsForeignFlags) VIPS_FOREIGN_SEQUENTIAL) access=((VipsAccess) VIPS_ACCESS_SEQUENTIAL) - vips cache : copy in=((VipsImage*) 000001f7c4720020) out=((VipsImage*) 000001f7c4720340) - vips cache+: flatten in=((VipsImage*) 000001f7c4720020) background=0 out=((VipsImage*) 000001f7c47201b0) - vips cache+: cast in=((VipsImage*) 000001f7c47201b0) out=((VipsImage*) 000001f7c47204d0) format=((VipsBandFormat) VIPS_FORMAT_UCHAR) - vips cache+: linecache in=((VipsImage*) 000001f7c47207f0) out=((VipsImage*) 000001f7c4720b10) tile-height=16 access=((VipsAccess) VIPS_ACCESS_SEQUENTIAL) persistent=TRUE - vips cache+: sequential in=((VipsImage*) 000001f7c47207f0) out=((VipsImage*) 000001f7c4720980) tile-height=16 - vips cache : ppmsave in=((VipsImage*) 000001f7c4720020) filename="x.ppm" strip=TRUE - $ vips flatten CQ2nhMO.png x.png $ vips getpoint x.ppm 0 0 108 73 36 $ vips getpoint x.png 0 0 108 73 36 $ convert CQ2nhMO.png -strip x2.ppm $ vips getpoint x2.ppm 0 0 120 82 41 ``` /cc <@!310374889540550660>

If you expect a similar output as that produced by ImageMagick, you can try this: ```bash $ vips extract_band CQ2nhMO.png x.ppm[strip] 0 -n 3 $ convert CQ2nhMO.png -strip x2.ppm $ sha265sum x*.ppm 72096cb14d7f9119a726dbdfb55c62452551557c906d2fcae1872245f5bd3121 x2.ppm 72096cb14d7f9119a726dbdfb55c62452551557c906d2fcae1872245f5bd3121 x.ppm ```

🤔 Hmm, Ok, not that I need the same result, rather I need to know which behavior is more correct (when ImageMagick drops transparency it's not good, although transparency is not really needed in this image)

IM just gives the RGB (which is nice if you want to see invisible pixels), if you want it to flatten you have to do `-background white -flatten`

Or whatever other background color

What is more correct is a matter of taste, I'd say, but not flattening does show stuff you otherwise wouldn't see so in most cases flattening is the 'right thing' to do

(keeping the alpha is the real 'right thing' of course, but ppm cannot do that. You can use pam though)

Yep, but not all formats/encoders accept pam

(which reminds me, we should maybe add pam as in/out formats in jxl)

Source with transparency

Also not sure what is the more correct behavior in these examples (although mostly for my case the experimental encoders didn't support transparency, but it seems that here after VIPS they get less "useful" pixels, so the image is compressed better)

However, on these images, the vips result is more suitable for my purposes

im one seems like it just strips alpha channel and leaves whatever color was underneath

Also about junk alpha pixels

<@!794205442175402004> Btw, JXL's premultiply option in that PR can't remove invisible pixels yet?

Premultiply implies removing invisible pixels. But we could also do something to make invisible pixels compress better in the non-premultiplied case, that's not implemented yet

libvips ships two win binaries: one tagged as "web" which only enables trusted file formats (regular jpeg, etc), and one tagged "all" which also includes support for weird things that are probably not yet safe on untrusted data (nifti, fits, etc.) the "all" binary for libvips-8.11-rc1 doesn't yet have jpeg-xl support built in, but only because we've not had time --- we expect to add jpeg-xl before 8.11 final assuming we can wrangle the cross-compiler into submission etc.

cwp2 ```-av1 ................... use lossy AV1 internally instead of lossy WP2``` 🤔

Is that how JXL that can be transcoded to JPEG look better than their JPEG work? https://imsc.uni-graz.at/hollerm/papers/tgv_jpeg_visapp.pdf

So that JXL's which are JPEG 'compatible' are just better, because they use a nicer decoder?

I think it would be something like this (but I'm not sure if it's already implemented): https://github.com/google/knusperli

Yeah

I came around this: https://github.com/victorvde/jpeg2png

jpeg2png has a nice short explanation about how it works in the README

I'm wondering if it is possible to just add the -p parameter for each block as another color channel in JPEG.

And if decoders that don't know about it would just ignore it.

Also <https://github.com/ilyakurdyukov/jpeg-quantsmooth>

it's very hard to do this stuff properly without oversmoothing

JXL does have a nice restoration filter but JPEG recompression leaves that off by default

That's why I'm thinking about adding the -p tuning parameter per block basis.

So you get a crappy JPEG that everybody can load.

if you notice any quality improvement it's likely just due to float DCTs

And a slightly less crappy JPEG if you have the right decoder.

I have no idea what libjpeg will do with >3 components... probably assume it's CMYK

So, stuff it in an APP segment then?

that could work

(I checked, you can do CMYK and YCCP with 4 channels)

The 4th segment has the nice advantage that I can just encode it at the very end if I use a progressive JPEG.

what smoothing algorithm do you plan to use?

(the idea is that I can have a lot of sharpening for text and less for faces...)

(note that jxl does allow to do what you're saying, i.e. controlling the smoothing per-block :P)

Total variation

mhhhh, I suspect it will be rather oversmoothed

Yeah, but I like stuffing more fancy things in old things so that it works everywhere 😉

Why would it?

The result would still encode the same.

because minimizing total variation is not the correct thing to do near edges

Yes, that's why I have the tuning parameter.

also, it would be very, very slow

but that's what you get with anything that uses optimization to find the unquantized DCT coefficients 😄

I spent about six months trying to find something that decodes in a reasonable amount of time and doesn't oversmooth for JPEG XL, initially I was trying to guess what to dequantize coefficients to (but that didn't work), but in the end I went for something like a selective gaussian filter

Yeah.. it doesn't have to be to nice... optimizing the first quotients by a bit might still minimize most of the typical artefacts and still be somewhat fast.

So, then I use your experience and look into selective gaussian filters..

one thing I would try if compute was not an issue would be trying to find DCT coefficients that result in a fixpoint for that kind of smoothing

i.e. use as a loss the delta caused by a selective gaussian

might not even need parameters in the JPEG itself

Well, you could have sharp ringing as an JPEG artefact that you want to smooth out...

And at the other point you have sharp text.

Or are I missing something here?

that's correct

I suspect you can use the amount of nonzero DCT coefficients to get a guess of how much smoothing should happen

So, I might still need a parameter (1-2 bit per block) in the JPEG?

Oh good Idea.

but if it's too complicated to figure out, parameters are a solution 😛

I don't remember if I tried *that* one, it's probably not perfect even if it works somewhat (or it could be that it was just too complicated implementation-wise in JXL...)

It should be fast enough that a bit of webassembly can read all JPEGs in the page and transcode them to blobs of JPEGs with less quantization.

eh, good luck with that 😛

you have about a 5x margin over libjpeg-turbo I believe

Least effort for user. Just add a JS xD

maybe 10x

Yeah, I bet that should be no problem if you limit it only to small images (those where everybody can see the artefacts)

without SIMD on wasm, I foresee problems in your future 😛 even with SIMD, I'd expect something that does more than 3 optimization steps to not be an option

Well, I think at least removing banding would be possible without actually doing the IDFT.

Do a bit DC smoothing and add 3 low frequency AC values.

right, progressive decoding for DC does that in libjpeg-turbo now

it might be interesting to see what happens if one leaves those AC coefficients there if they're inside the quantization range

JXL had something like that, but it created *other* artefacts

So, I might just try that on blocks that don't have any AC values?

And the neighbours don't have them either?

my attempts at that in JXL ended up in overshooting

😄

anyway, it's sufficiently late here that I probably should be sleeping 😛

Good night!

You may want to look into JPEG XT then.

Generally the problem with gracefully degrading backwards compatible improvements is that nobody even notices that there are potential improvements they're missing out on, because "it already loads just fine, don't need a new decoder".

Is there a way to get the specification? It looks a bit expensive on the ISO webpage?

Not afaik, but you can look at Thomas Richter's libjpeg, which implements it

https://github.com/thorfdbg/libjpeg

That's also the only complete implementation of JPEG afaik, including arithmetic coding, hierarchical, lossless, 12-bit, etc — all the stuff that was in the original 1992 JPEG spec but isn't usually implemented so it's not usable in the 'de facto' JPEG standard...

<@!208917283693789185> <@!310374889540550660> Hmm, one more thing with VIPS, how can I force saving only in binary color PPM (P6 magic number), because sometimes images are automatically converted to gray scale PGM (P5) etc., that's good to save space, but the problem is that there are applications that only accept binary PPM (but not support PBM, PGM, PAM). In ImageMagick it depends on output file extension and by default it is something like PPM (P6), PGM (P5), PBM (P4), PAM (P7)

In python you could write: image.colourspace("srgb").write_to_file("x.ppm", strip=True) and you'll always get a 3-band (channel?) binary PPM libvips doesn't use the file extension to decide the PPM type, it picks the Pn from the image colourspace

or at the command-line: vips colourspace input-file t1.v srgb vips copy t1.v output.ppm[strip] depending on how you name your temporary intermediate files

I see, I also tried the `--interpretation` option (but it doesn't seem to be for this) Also I noticed that all-build for Windows has `libMagickCore-6.Q16-7.dll`, but options like `magicksave` don't work

`vips copy x y --interpretation zzz` just changes the "how should I display this?" hint on an image, it doesn't change any pixels you need `colourspace` if you want to transform pixel values

`magicksave` ought to work on the "all" windows build, what error are you seeing?

```vips.exe: unknown action "magicksave"```

<https://github.com/libvips/build-win64-mxe/releases/tag/v8.11.0-rc1> `vips-dev-w64-all-8.11.0-rc1.zip`

I see: $ ./vips.exe magicksave ~/Pictures/before.png ~/x.bmp --format=bmp $ ie. I could use magicksave to write a BMP file

oh, I don't know, I didn't make the 8.11-rc1 win binary, I'll check that was with 8.10.6

```vips.exe magicksave 1.png 1.bmp --format=bmp vips.exe: unknown action "magicksave"```

It's working for me. I see: ``` $ unzip -qq vips-dev-w64-all-8.11.0-rc1.zip $ cd vips-dev-8.11/bin/ $ ./vips.exe magicksave save file with ImageMagick usage: magicksave in filename [--option-name option-value ...] where: ... etc. ``` That's on win10. Perhaps it's picking up a different version? What's your PATH set to?

I checked in the same directory, hmm, maybe I should specify Path

Hmm, yep, that works now, thanks

It seems that IM convert with `-background black -alpha remove` does something similar with transparency as the VIPS by default (at least visually) 🤔

Knusperli works quite well at removing painfully obvious banding and block borders while not removing sharpness excessively. That "fake sharpness" is sometimes actually kinda helpful, someone wrote about it in a comment under Hacker News post about Knusperli. https://news.ycombinator.com/item?id=16616025

The paper looks interesting, but just like Luca said before, it's blurry af because of TV/TGV. In Figure 7 in that PDF I actually prefer the "standard decompression" instead of their reconstruction because lots of actual detail got removed together with artifacts.

Yes, I prefer something like Knusperli, other similar decoders are too smooth and blurry, it may be good for very bad quality, but for the rest I would even prefer some artifacts and blockiness

You can see in the image below (again, from Hacker News post, but this time about jpeg2png) that the "fake sharpness" phenomenon is retained perfectly by Knusperli.

https://mod.ifies.com/f/200710_lena_decode_comparison.png

By the way <@!179701849576833024>, is something Knusperli-like used in JPEG XL?

nope

too slow, it requires an image-global optimization step...

the restoration filter does probably a bit worse on block boundaries, but a bit better on other artefacts and it's local and reasonably fast

In Jpeg XL I noticed some banding fixes when decoding (although I don't remember if I enabled any options or if it was the default one a long time ago)

you mean for JPEG input?

Yes (when decoding lossless Jpeg to PNG/higher quality Jpeg)

I'm not sure *why* xD the only explanation I can come up with is that we use float DCTs and only convert to int in RGB while IIRC JPEG does that in YCbCr

Why? Idk if the Hacker News guy is wrong, but they wrote: > Jpeg2png minimizes the total variation over the whole image, and knusperly only along the boundaries of the blocks.

ah that's likely the case

but still, your choices in a block will affect other blocks

and that has a domino effect where IIRC you can't be really sure that block (0, 0) won't affect block (1000, 1000)

Btw, were there any experiments with Wavelets during the PIK/Jpeg XL development?

not as far as I know

well, Squeeze is a wavelet AFAIU

Does AV1 do similar filtering?

It sometimes looks quite blurry to me.

av1 does a lot of filtering

it has cross-block filtering, directional filtering, and one more filter still

page 4 here https://www.jmvalin.ca/papers/AV1_tools.pdf gives some explanation

https://twitter.com/daemon404/status/1401914442921791496

I'm also very interested in very fast and efficient mode in JXL, I wonder what Qlic2 by Alex Rhatushnyak is based on or is it something that went into lossless PIK and JXL s3? Although Qlic2 is much faster, also lossless PIK is faster and more efficient than the current JXL s3

Related question: how did lossless mode work in PIK and how is it different from JXL?

Lossless pik was basically the same thing as `cjxl -m -s 3`

That is, Weighted Predictor, and a fixed ctx model that uses only the weighted predictor max err (WGH in jxl art terms)

Lossless pik was hardcoded for that, and for 8-bit or 16-bit only, and possibly was a bit faster and more efficient than current cjxl -s 3, but it's basically the same thing

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

PNG with ZSTD instead of zlib would be so much better

Notwithstanding existing lossless codecs that are more optimized like jxl and webp lossless but it would be a massive improvement

As already discussed, switching to the new codec will be even easier and cause less confusion and problems than incompatible changes to the old formats

It's a thought experiment more than a useful codec

And it's not just only zlib inefficiency https://twitter.com/jyzg/status/1253714896270868481

Btw, in some mobile games I found modified incompatible PNGs with LZ4PNG header

Ah yes

Combine EVEN WORSE compression

With PNG

For incompatibility galore and massive files

I suspect it's for faster loading? But I wonder why, regular png decode is pretty fast

Probably (LZ4 is 10-12x faster), there may have also been some other modifications for better compression of a specific type of images/resources

I managed to build libvips with JPEG XL support on Windows, see commit https://github.com/libvips/build-win64-mxe/commit/b7926cd212044a4ed4db6297a459e2297b2368d5.

(It's built as a dynamic module so users can delete `lib/vips-modules-8.11/vips-jxl.dll` if they want to)

So far only tested on Windows x64, I still need to test the i686, armv7 (i.e. Windows 10 IoT) and arm64 builds.

Leonardo wrote a book: https://www.amazon.com/Even-stars-die-history-digital-ebook/dp/B096G6TSF9/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=&sr=

The story of how the Moving Picture Experts Group (MPEG) was conceived and established. This book is structured in six sections each with a different number of chapters and parts of the story: Section 1 describes the world of media before MPEG. Section 2 recounts the birth of MPEG and the story of its first 3 standards. Section 3 explores some of the media-related areas in which MPEG operated. Section 4 assesses some of MPEG’s diverse characteristics. Section 5 tells the causes of and mourns the death of MPEG. Section 6 describes the constitution, the work MPAI did so far and future plans.

How much of this applies to JPEG?

I have never been in MPEG but it does resonate with me quite a bit...

I haven't been to MPEG either, but the ISO bureaucracy is a real thing, also in JPEG. I don't think that's the main thing that was wrong with MPEG though. I think the main issue is that 2/3 of the MPEG attendees are patent trolls.

Building a codec with a committee where most people are just trying to get their patented stuff in it, I can only begin to imagine how tiring and annoying that must be as a codec engineer who just wants to make a good codec.

``.png``

GIMME THE ORIGINAL `.JPG`, I WANNA KNUSPERLI IT

I want so see this

I'll have to find it

This is the only true jpeg

At least this is somewhat readable <:kekw:808717074305122316>

No idea what you're doing, but it looks cursed

I think it's too much blockiness even for Knusperli...

And are you sure those deep-fried JPEGs are from originals?

I edited it myself

Well, took a like 2 mintues, because compression hides all imperfection anyways ~~yes, this is my level of boredom~~

Nice

Avif pog

Now do the same comparison with Knusperli version, it won't be as blocky

Not home anymore sadly <:cheems:720670067091570719>

```Encoding [Modular, Q-500.00, kitten] Compressed to 17930 bytes (0.016 bpp). 3000 x 3000, 1.15 MP/s [1.15, 1.15]```

JXL modular, Quality negative 500

Modular Q-500? cool

that's wrong on so many levels...

https://c.tenor.com/jP0CrJmmeVQAAAAM/cant-decide.gif

Luca trying to figure out if he should be most offended by the word "pizza" on something that is clearly not even remotely related to actual pizza, or by the Q-500 modular 😂

you know me well 😜

Stop torture italians with bad pizzas, we prove emotions

Opinions on pineapple and pizza?

My opinion: sure, why not. Many great pizzas don't have pineapple, and if you're going to use good mozarella then probably pineapple is not the best combination (the traditional tomato and basil is pretty much unbeatable), but pineapple can be a nice thing to put on a pizza. I like it most in combination with bell peppers, spicy peppers, mushrooms and strong cheeses (old ones, that are strong enough to compete with the acidity and flavor of pineapple).

Italian’s reaction to Hawaiian Pizza 😛 https://www.youtube.com/watch?v=EDUy3Y_w9Tk

we're not friends anymore 😛

yup, I've seen that - I wish I understood the dialect though! 😄

I put anything on a pizza (well, anything vegetarian)

I also put anything in a spaghetti sauce or in a lasagna

I like it but then I have to fend off pitchforks and torches from people

<@!424295816929345538> <@!416586441058025472>

that sentence would be more acceptable if it was "on flatbread with tomato" instead of "on pizza" 😛

Ok, fair enough

I abuse the words pizza, spaghetti, lasagna to mean a lot of things that have a vaguely similar shape

that said, I know a person from Sicily that likes fries on pizza...

sometimes I wonder where the world is heading xD

Fries on pizza, hm I wouldn't do that, I consider the bread to be enough of the starchy stuff not to require potatoes too

Are potatoes considered a vegetable in Italy?

In France they are kind of treated like a vegetable

While here it's more like the bread/pasta/rice part of a dish, not considered a vegetable

photos not mine

from internet there are

only poors eat those things

because spending 4 euros for a pizza is considered poor

people also like vegetables in italy

it's more for the *fried* part 😛

we call it "americana", and it also splits opinions 😛

other codecs becoming food

we stop here

i shouldn't post images

btw, here in Zurich, a reasonable pizza is about 20 chf 😛 (~ as many euros)

is called other codecs not screenshots and youtube videos

One thing that has changed here in the past decade or two, is the way Turkish kebab or durum is usually prepared

Inserting fries between the bread or rolled inside the durum is now kind of standard as far as I can tell

Belgians do like fries a lot

Our most famous dishes are: Moules frites (mussles with fries) Biefstuk-friet (steak with fries) Stoofvlees met frieten (stew with fries)

Seriusly, I can somehow accept a bad pizza but please, stop america to use ketchup on pasta, is gross, is a crime

what about ketchup on pizza? 😛

I've seen that, and not even in the US!

Please, why, stop

Ketchup as a strong flavor (also acid?), is good on salty things but why use it on pizza or pasta?

It completly replace pasta and other ingredients' flavor

Is a stereotipe that italian can't apreciate other culture food

But please stop mix ketchup and wheat

What else to use on pizza?

Tomato, all sort of cheese and meet, also egg, in special pizzas also sardas. A lot of vegetable

Only not use fruit and strong salsa

but I like pineapples 😄

I always put them with as liitle space as possible between each piece on my pizza. ^^

I like choccolate but i don't put it on pizzas 😆

https://www.reddit.com/r/StupidFood/comments/bh5awz/chocolate_pizza_is_getting_mainstream/

I've seen this monstrosity in Poland... NOOOOOO

do you have link with the new webp2 comparison

https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#meg-20110701-japan-expo-02&AVIF-AOM=s&WEBP2=s&subset1

pizza alla nutella? 😛

veluca is from north or south

or center

~~~ Genoa

but I went to university in Pisa

nutella != choccolate, also is a dessert not a tomato/nutella pizza

ok, ok 😛 (yeah, chocolate + tomato = ?????)

nutella is not *that* different from chocolate...

not equal also

chocolate + tomato can be nice, some Mexican mole sauces do that

current codecs are expensive

the only good codec is cavif rs that can encode good explicit contnet

thanks to good sharpening filter that cover full color range

new approaches faster speeds, better compression, better quality size are still in study

i remember a metrics called IQA

cavif rs it has blurriness image look only red and white

it has its artifacts should be used only with high quality images

for normal images is evident the lack of adaptive quantization

making some images seem too fake

and flaccid body

eddiezato builds of jxl don't work on windows 7 sse4.1<@!387462082418704387>

The integration is fake no release no builds no automatic conversion to jpg when You copy to old version of word. No full integration in any text applications.

You cant Say people use jpeg xl

I experimented and dropped 'Scalar'. I'll bring it back next time.

We don't have a good windows viewer plugin and you want a multi-application OS level automatic coversion?

remind me again what's wrong with the mirillis one?

It's on a very old version of libjxl, crashes on some images and doesn't support animation

animation I care less about

have you tried filing an issue?

possibly even asking to move it to libjxl, I dunno

They don't seem to be very active and don't read issues

crashes on a lot of images

I guess it's just a one-time thing with no further support.

> With standard uncompressed file formats, such as RGB TIFF, whew, 2004 was a different time, wasn’t it

where is that quote from?

(btw TIFF is still a thing in 2021, for multilayer/multipage, for float24, for lossless CMYK, etc it's still the only option, kind of)

it’s from the manual of the Canon PowerShot Pro1

an old model from 2004, discontinued in 2006

true, TIFF is still sometimes used, though it’s rare for it to be uncompressed nowadays, isn’t it?

typical TIFFs I see are either uncompressed or RLE 'compressed'

there are TIFF extensions for all sorts of compressed payloads but those tend to be not well supported

oh, good to know; when I export tiff from darktable, it’s generally with deflate

haven’t checked what Hugin and DxO PhotoLab do exactly

I did see limited compatibility but I assumed it was either general incompatibility with tiff, or because I exported as floating point

(my main reason for using tiff in the first place)

Deflate is also not very effective in tiff, iirc it is either without prediction or with Left prediction only (and I think there's only prediction for uint8 and uint16)

the full sentence in the manual was:

> In addition, although a RAW file is larger than an equivalent JPEG file, it is still only approximately one-quarter the size* of an uncompressed RGB TIFF format file, making it relatively compact.

> * As measured by Canon’s testing standard.

https://files.canon-europe.com/files/soft24019/Manual/Pro1_CUG_EN.pdf

https://twitter.com/miltinh0c/status/1392944896760238080

🤔 <https://chromium.googlesource.com/codecs/libwebp2/+/bcb5089b06912771d0af46742abca489e55f7da4>

<https://forum.doom9.org/showthread.php?p=1945019#post1945019>

<@!321486891079696385> continuing our discussion from <#794206170445119489> here in order not to derail that channel.

I've identified 3 major Dark Shikari's contributions that helped x264 become a quality king (and their respective Doom9 threads): - Variance Adaptive Quantization (VAQ) https://forum.doom9.org/showthread.php?t=135093 - Psychovisually optimized rate-distortion optimization (Psy-RDO) https://forum.doom9.org/showthread.php?t=138293 - Macroblock Tree Ratecontrol (MB-tree) https://forum.doom9.org/showthread.php?t=148686

May be helpful to AOM devs and rav1e devs (including you ofc)

libaom currently does something like this (x264 with PSNR tuning):

https://web.archive.org/web/20150119170631if_/http://x264.nl/developers/Dark_Shikari/imagecoding/x264_psnr.png

I want it to create "fake detail", something like this (x264 at its usual settings):

https://web.archive.org/web/20150514184757if_/http://x264.nl/developers/Dark_Shikari/imagecoding/x264.png

Photos taken from this article: https://web.archive.org/web/20150319214453/http://x264dev.multimedia.cx/archives/541

Variance AQ Megathread (AQ v0.48 update--defaults changed) <https://forum.doom9.org/showthread.php?t=132760> VAQ 2.0 <https://forum.doom9.org/showthread.php?t=136445> New B-pyramid testing thread <https://forum.doom9.org/showthread.php?t=152761>

Introducing the next generation in video encoders: x264 Revolution! <https://forum.doom9.org/showthread.php?t=146064>

Also, I've been on x264 IRC since its creation and followed the development, it's a pity there isn't such an active and open community of new video codecs with a leader like DS now, maybe daala and rav1e could do, but they are much less open and active (just like in the old days with Theora and other open formats)

> I've been on x264 IRC since its creation and followed the development Wow, a veteran... DS was indeed a damn good leader.

1. That one is currently being worked on by 2 rav1e folks. Anyway, I'm lucky to have my own personal laptop at work, but look at the difference prioritizing sharpness a bit over blurriness. Only difference? `sharpness=0` vs `sharpness=2` `avifenc -s 2 -j 4 --min 0 --max 63 -a end-usage=q -a cq-level=61 -a color:sharpness=X -a tune=butteraugli -a color:enable-chroma-deltaq=1 -a color:aq-mode=1 -a color:deltaq-mode=3` What do you think? https://slow.pics/c/FttY4yxx 32kB end file sizes.

I think `sharpness=1` would therefore be our best compromise 🙏

I think it would be better to resize to 840x1120 to match the images in the article (because this is overly strong compression where it is hard to say what is better)

I agree with <@!111445179587624960>, but I can already tell from the full-size (non-downscaled) encode that `sharpness=2` is *kinda* better. There are some nasty artifacts though, e.g. coding noise in the center of dog's face, I see too much DCT components. Look again at x264 tuned images I linked above, the fake detail in them is *directional*-looking. Maybe DS fiddled a bit with directional predictors? It's a topic to research.

To be fair, the image went from 3MB to 30kB, which I'd a massive decrease.

x264 intra would likely look a lot worse.

Of course, for such high compression, you are better off scaling the image down.

Hello <@456226577798135808>, Thank you provide this information 🙂 A little curious, av1 dev will implement those amazing features in av1 encoder? or have some alternative features is already implement in av1 encoder? > BlueSwordM > 1. That one is currently being worked on by 2 rav1e folks.

I read some av1 technology article, look like for now av1 encoder don't have similar features like --psy-rd. (maybe use tune butteraugli have some Psychovisual optimized?, I not sure)

Everything a lossy codec does is in a way a form of psychovisual optimization - the goal of lossy is always to lose stuff you don't see.

Some encoders are of course better at it than others, and some codecs are more suitable for it than others.

But all lossy coding tools are designed (or should have been designed) specifically for that goal.

If they're designed for something else, it's because an engineer somewhere was confusing some easily computable number like psnr with the actual goal of the codec/encoder.

Look like av1 use Just Noticeable Distortion (JND) to make some Psychovisual optimized, I don't really understand this features, <@!321486891079696385> Could you teach me some knowledge about JND? 🙂 > https://ieeexplore.ieee.org/document/8954513

<https://encode.su/threads/3557-Low-Complexity-Enhancement-Video-Coding-(LCEVC)?p=69923&viewfull=1#post69923>

Scope has 🔗 for every topic.

LCEVC has very interesting ideas to encode small details and high frequency part separately, and the rest with reduced resolution by any of the available codecs (moreover, encoding becomes much faster)

However, it is still unclear how much better this is in practice

I have heard claims of great results, but I am somewhat sceptic - I think it was mostly designed to have something with a royalty-free baseline (to compete with aom) and options for patented extensions (because mpeg is gonna mpeg)

Claims I have seen so far talk about PSNR, which I think is a particularly bad metric for approaches like this, because even just encoding a downscaled image and upscaling it again (without any added detail) is something that is amazingly good for PSNR - after all, PSNR measures an average error and the average error will be quite good automatically with hierarchical approaches.

isn't that EVC, not LCEVC?

EVC is the royalty-free codec, LCEVC is the mechanism to layer two codecs hierarchically, I think intended thing is to do EVC for the base layer and VVC for the 'extra details' layer

and make videos that way that use a 'royalty free' codec but to view the high res thing you need to have the patent-encumbered codec

I dunno, I'm just speculating based on impressions from the sideline

https://youtu.be/B_d9C-I6kX0?t=231

https://www.lcevc.org/

> In particular, the key performance requirements were defined as follows: > > When enhancing an n-th generation codec (e.g., AVC), compression efficiency for the aggregate stream is appreciably higher than that of the n-th generation MPEG codec used at full resolution and as close as possible to that of the (n+1)-th generation codec (e.g., HEVC) used at full resolution, at bandwidths and operating conditions relevant to mass market distribution;

I've seen that slide before (I had PSNR in my head but it did indeed say VMAF — not that the difference between those two metrics is huge)

I am curious what kind of encoders they used there — do you see that x axis?

a logscale that goes from 1000x realtime to 100,000x realtime

are they comparing a somewhat optimized superslow reference encoder with a totally not optimized superslow reference encoder here, or what?

only Netflix can afford to spend _that_ kind of compute on video

For AVC as far as I remember they used x264, for more modern ones like VVC - reference encoders, for AV1 - libaom

I have no time to watch that video, but I think the more realistic thing is that they have something that isn't actually better than the codecs it uses, and LCEVC(1:2 video in h264, 1:1 residuals in h265) produces something that is a bit worse (slightly slower, slightly less dense) than just doing 1:1 video in h265, but still significantly better than doing 1:1 video in h264

and same if you do it with h265 and h266

But, LCEVC gives more benefits to older codecs, in modern codecs as far as I understand some similar methods are used internally, like for VVC benefits are only about 7% or less (but there is still an increase in encoding speed, due to lower resolution)

yes well older codecs have smaller macroblocks etc so they are less good at high res

it's a nice idea and a good way to make gracefully degrading upgrade/adoption paths for new codecs, but I don't think it can be better than just using the best codec — I might be wrong though

The interesting thing is that this high-frequency layer does not require a lot of resources for decoding and can be on JS or supported in the player (when the main stream will be in normal format)

Wait they have a codec for the high res layer itself?

Yep

I thought they only standardized the upsampling method and how to apply the residual layer to it, not how to encode the residual layer itself

Oh so they also specify a specific residual encoding then, that is fixed and cannot be upgraded/improved?

🤔

How does this not mean you can recursively make an n+5th generation codec right now by doing lcevc five times with an n-th generation codec at the base?

If the claims are true, why not just make a recursive lcevc codec that applies residuals 12 times on a 1:4096 video which is just a single pixel? Should be ultra fast and 12 generations ahead of its time

There's likely a downside we haven't seen with LCEVC yet since not many people haven't tested it.

Well it could be it is great but then why isn't it a coding tool already in all the other modern codecs?

Actually, it is already in some ways. Grain synthesis/noise synthesis is "just" an enhancement layer designed to bolster psycho-visual quality significantly without huge computational/data rate increases.

The idea itself goes back at least to the 1992 jpeg spec, which describes exactly that: normative upsampling, residual encoding. It was called hierarchical jpeg.

"scalable layers" is what it is usually called in video codecs iirc, and I think x265 and av1 do support that

I think this only works well for half resolutions and such, moreover the LCEVC layer also consumes resources and bitrate and it always stays in full resolution

It is also unknown how well this enhancement sub-layer compresses

So they have residuals at half res first to correct artifacts, then at full res to add detail?

No way this is a good idea for density

Encoding artifacts and then encoding residuals to remove artifacts, no way that that's a good idea

But we'll see where it goes

It's also bad that all this is not royalty-free (but as they say very cheap and loyal)

Continue Just Noticeable Distortion (JND) discuss, https://discord.com/channels/794206087879852103/805176455658733570/854425055224135720 I try to find more JND information, but I can't find too much, I guess av1 Just Noticeable Distortion (JND) and jxl just noticeable error(Butteraugli distance) probably have some similar place?

Some detail about JND 01

Some detail about JND 02

Some detail about JND 03

I wonder if it would make sense to design a video codec that is not designed for hw decoding, but designed for sw decode of intra frames and hw decode of inter frames. So e.g. something like jxl for the keyframes (one every 5 or 10 seconds or whatever) and av1 for the interframe part.

AV1 would at least have to support XYB. Color accuracy gets quickly bad for video codecs and you notice slight changes easily since your idea would be like a flicker test.

It would be nice if cjxl supported adaptive quality. E.g. -d 1 for frames shown at least 1s, -d 2 for frame times between 500ms and 999ms, and -d 3 for everything below.

For now av1 encoder follow this standard, probably av2 will implement xyb. > https://www.itu.int/rec/T-REC-H.273-201612-I/en

I don't understand why JND still include SSE (The sum of squares due to error)? In theory MSE, RMSE, SSE is without Psychovisual optimized.

A JND should be something psychovisual, but what kind of aggregation/pooling you do is an orthogonal question: mse is the 2-norm, so basically it's an average where good pixels can compensate for bad pixels, while max-butteraugli is a 'worst case' pooling, where a single bad spot can spoil the whole image.

Ssimulacra and p-norm butteraugli are somewhere in between those two extremes.

Yes, not just for animation (which I don't think is a strong point of jxl anyway) but also for single frames it would be nice to have local control over the fidelity target to reach.

Well inter frames would still be based on decoded intra frames, but yes, it would help for that if they would use the same color space.

Maybe we should convince av1 dev use butteraugli 3-norm or 6-norm in JND features? (this ppt is from AOM Summit 2021)

Maybe such a hybrid codec with strong intra, not restricted to hw limitations, and classical inter (restricted to hw implementability) could combine the benefits of hw (battery life, offload from cpu) with the benefits of sw (stronger entropy coding possible etc), and make a codec that is truly suitable for both video and still.

1. Following my point: aomenc already has variance AQ. However, by default, it is not well tuned, and does not work super well in video, but there are ways to improve it. 2 rav1e people are working on making the x264 AQ implementations even stronger and more temporally aware. 2. Already present in rav1e, and I'm not sure about aomenc(although it has psy-rd already in the form of `--sharpness`, but not sure about pure psycho-visual psy-RDO) 3. Macroblock Tree Ratecontrol = Temporal RDO. Already present with rav1e, aomenc and SVT-AV1. rav1e implementation is currently the strongest I've seen within encoders, aomenc is currently being improved nicely, and SVT-AV1's implementation works, although it is of lower quality to achieve higher through(lower quality in this case = more bpp spent).

Thank you very much for your help <@!321486891079696385> 🙂

Nice to know! I've got a bit different ideas, though, but still: you're working on that and that's great.

I wonder how exhaustive libaom is at slowest speed. Is it exploring most of the space the bitstream can express?

the more interesting question imho is, is it optimizing for the right thing it its exploration?

That probably not, I don't think anyone really knows what exactly the right thing is, let alone have an algorithm for it, let alone one with a reasonable speed

But assuming you really want to optimize for psnr, say

Is it close to trying everything it can to do that, or are there encoder choices where it just picks something without really trying to optimize close to exhaustively?

Yes, but there are places where it still lacks some... compute destruction.

For example, only rav1e does a bottom-up partition search at its slower speeds similar to this: https://discord.com/channels/794206087879852103/794206170445119489/854279720312242227

All other open AV1 encoders do top-down partition search, leading to some... dubious block choices in edge cases.

Partitioning is one of those things where I guess exhaustive is not feasible

But at least av1 encoders can in principle do any partitioning the bitstream allows, right?

Yes.

this is not the case with cjxl, which only does naturally aligned partitionings that do not cross 64x64 boundaries, while the bitstream allows floating blocks as long as they do not cross 256x256 boundaries