JPEG XL

to automate a bi t

so it uses a mixed with patches

what it does

anyway scope if you can suggest something

what quality set wp2

maybe i will try -q 92.39

but that is not a palette it don't change colours it reduces image quality

so what i need do i need to specify a -z command in wp2

I assume -q 96-99 does something with the lossless codec (with preprocessing to make the image closer to the predictions, or something)

In wp2

or is not supported palette at the moment

anyway i want less loss possible

less distortion amount imaginable

less artifacts visible

Shelwien Shelwien is offline Administrator Shelwien's Avatar Join Date May 2008 Location Kharkov, Ukraine Posts 4,242 Thanks 334 Thanked 1,468 Times in 846 Posts > attachment is downloaded as a jpg It a screenshot from file comparison utility. Blue numbers are different. > is the input 16bit? Yes, 16-bit grayscale. > Did you expect a 16bit output? Yes, FLIF and jpegXL handle it correctly. > What command did you use to generate the attachment? convert.exe -verbose -depth 16 -size 4026x4164 gray:1.bin png:1.png cwp2.exe -mt 8 -progress -q 100 -z 6 -lossless 1.png -o 1.wp2 dwp2.exe -mt 8 -progress -png 1.wp2 -o 1u.png convert.exe -verbose -depth 16 png:1u.png gray:1u.bin > (webp2 only handles 10bit samples at max, btw) That's ok, but cwp2 doesn't say anything about -lossless not being lossless.

There is no universal advice on the choice of quality values, if they were, there would be no choice in encoders, it all depends on the content and image size limits

what is libwebp2 max resolution in width and height

also libwebp

so i will try with one image

16k by 16k

how do you know

i see no mention in libwebp2 chromium

has it changed?

Because I tried to convince pascal to bump up the maximum to something higher, and I failed

and the fork ssignnet did of wp2 + some code of jxl when it was not standardized

what resolution support

the test program

he did

pingo authors

png compression cmd

i know is rarewares

first step works with modular

now i need to have some scripts

The width and height are signaled in 14 bits each so it's a hard bitstream limitation that is there on purpose because pascal is convinced that 16k is enough for all web use cases so the format doesn't need to support anything larger

this is like what i did to my image

filtering more

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

introducing like an hdr camera almanence effect

then filtring

it could help to compress

is bad

but is faster and good

i think estimated quality would be less

imageranger when it will support jxl will detect a lot of low quality images

wp2

for %i in (C:\Users\User\Documents\a2\*.png) do cwp2 "%i" "%i.wp2" -o -q 99.03 -effort 2

someone knows the correct script

All these extra options plus speed 5 where a bunch of optimizations are turned off probably isn't a big help

If in doubt I'd use speed 7

i want to convert batch images with wp2

https://groups.google.com/a/aomedia.org/g/av1-discuss/c/4o0TRIZXa10 New aom_tune_metric enum value: AOM_TUNE_BUTTERAUGLI. The new aomenc option --tune=butteraugli was added to optimize the encoder’s perceptual quality by optimizing the Butteraugli metric. Install libjxl (JPEG XL) and then pass -DCONFIG_TUNE_BUTTERAUGLI=1 to the cmake command to enable it. Someone tried new av1 --tune=butteraugli?

don't work

with cmd windows 7

it said invalid

command

with o after it says you need to specify folder to do batch

https://tools.ietf.org/html/draft-zern-webp-00

they haven't had this for years, why now?

Now that WebP is supported by all major modern browsers (with Apple finally adding support) there has been increasing pressure to adopt it to save space over legacy JPEG, but also some pushback due to it not having an official IANA media type. For example WebP is being added to EPUB, but W3C wants the media types in its specification to have an official IANA registration.

I see. makes sense.

I wonder what the media type for WebP2 will be. `image/wp2`?

`image/vvp2`

I assume it will be `image/webp2`, but hopefully they will officially register it this time once it is stable, instead of waiting another 10 years.

01052021 doom9 jamaika

here's settings

https://discord.com/channels/794206087879852103/794206170445119489/839100479828525058

if you want to reduce more q77 mozjpeg image or you want less compression or lossless transcode ask someone more expert

because i don't know

for %i in (C:\Users\User\Downloads\5\*.png) do echo %i cwp2 "%i" -o "%i.wp2" -q 99.03 -effort 2

don't work

no one

but it don't display anything

only lists of file

i didn't used the command you wrote

after echo what i should write

i want to specify output folder

or do in the same folder

better do in same folder

i'm still on win7

no i want for the jamaika build

and i don't have time to ask which commti is

to him

thanks

is doing

running first command

for %i in (C:\Users\User\Downloads\apr5\*.png) do cjxl -q 94.6 -X 22.4 -Y 38 -I 0.68 -s 3 -m %i %i.jxl

ok 1h 35m for 43 mb of images

they were all in high resolution

but my cpu handled because of low effort

someone crashed on wp2

because of assertion it has problem to allocate memory increase memory to use palette

.cc

for %i in (C:\Users\User\Downloads\apr5\*.png) do cjxl -q 94.6 -X 22.4 -Y 38 -I 0.68 -s 3 -m %i %i.jxl for %i in (C:\Users\User\Downloads\jxl\*.jxl) do djxl %i %i.png for %i in (C:\Users\User\Downloads\in\*.png) do cwp2 -q 99.03 -effort 2 %i -o %i.wp2 for %i in (C:\Users\User\Downloads\in2\*.wp2) do dwp2 %i -o %i.png for %i in (C:\Users\User\Downloads\in3\*.png) do cjxl -q 78.079 -s 5 --epf=1 --noise=0 --dots=1 --gaborish=0 --patches=0 %i %i.jxl

these all commands

but they are written wrong

the double %i is not needed

i don't know why orum suggested

maybe because i crashed the cmd

maybe i did something wrong

ok

average size saving 50%

but faces get distorted

i couldn't recognize britney spears face

she still look 18

but i thought it was a cat at first glance

i don't think you can get 50% jpg reduction without using modular and those

using a stronger modular usually is not efficient

as wb said

<@321486891079696385> could you explain those guys, please? I don't have time, goshhhh...

best overall settings in aomenc-AV1 and SVT-AV1 rav1e-av1 currently doesn’t have grain synthesis, bad bad, aomenc-av1 strongest scenario : live-action, weakest scenario : animation, SVT-AV1 strongest scenario: 2D animation, weakest : generally slightly blurrier and lower quality.

thanks

with my fonts set at 10 pt i read the article in 12 seconds

why you are saying is a long article

i didn't perceived 39000 characters

are you sure is right?

anyway it only says the options he uses for encode videos in mass

but he don't specify if they are for ffmpeg, for aomenc or for fastflix

he only say cpu 6

and then noise value 12

i didn't understood from his cpu 6 commands

which are the denoiser settings

and the added grain settings

is only advice of settings like all posts of r/av1

Thank you, but by "explain those guys" I meant "rekt the anti grain synthesis guys from comments" 😉

gave it an attempt, not sure it will work out

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

https://twitter.com/PascalMassimino/status/1390281518640152579 I created those GIFs (Kornel’s giflossy magic), so what? You can always concoct an image that will compress best using a specific codec combo. More interesting problem to solve is to have a tool that will work better in most situations and will be easier to operate. Those shouldn‘t even be GIFs in the first place, but I lacked tooling/knowledge and the support wasn’t there for a performant cinemagraph (I tried some crazy PNGs with holes in them though which the videos were showing, but that was so much harder than GIFs). Animation in image formats should die and as often mentioned here, browser should just be able to display any video in the `img` tag…

https://twitter.com/jonsneyers/status/1390344481917083650?s=19

Don't feed the troll!

Guessing they mean with default settings?

That doesn't mean much. I can make a `mycjxl` that has -m -s 9 -g 3 -I 1 as default settings :)

https://twitter.com/ZiemekZ/status/1390363487042424838 😜

What options did you use?

That's strange... I used the exact same options as yours.

It's the version just before the latest sync.

26 415 🤔

Be good at what you do or have glow, pick one

Seems to be a lot of hit pieces on JXL recently. I say it's a good thing. Just means it's getting out there and people who support other formats feel threatened by it.

Btw, still don't understand why my comparison is considered mostly fan-art (it includes such images, but there are many other categories), especially these are mostly real popular images that are most common and found as lossless internet content, it lacks except sets of screenshots of text from social networks/messengers and various UI https://twitter.com/PascalMassimino/status/1390372475599560706

maybe people only look at the first few pages of the spreadsheet lol

might be a good idea to reply then... 😄

Agree, I went through an earlier one and ran my own calculations. Just because the number of art pieces ended up being like 10-12% greater than many other image types people were saying it wasn't representative. I don't feel that was the case just because some sections had maybe a hundred more than some other sections.

Maybe, but I've answered a similar question before, and I also don't want to start writing on Twitter, I only read it and on very specific niche topics But maybe I should make Details as the first Tab

I also find it funny that most of the AVIF articles don't even mention performance or act like it's a non-issue, but as soon as you talk about other formats... where are the performance numbers? Truthfully, everyone could include them... but AVIF is likely to look horrible with them included. I know WP2 was even worse than AVIF in the early days, not seen recent numbers though.

I agree with you, and the news cycle will pass in a day and most people will forget about it. I too have not responded to a number of the hit pieces. I see major flaws in methodology and very few actually showing their work. It just ends up not being worth it as they will come up with one excuse after another as to how their method was flawless while everyone else's was not.

It's a good sign indeed. It's a bit annoying when random people on the internet say that "your baby is ugly" but it's a lot more annoying if they do that with valid arguments (because then there might be an actual problem) than if it's just some rather unfounded "you suck" rant...

Yes, I would like to add to the comparison encoding speed as well, but I did not have the opportunity to do so, because for the accuracy of the results I need a separate completely unused PC and encoding must be performed several times with an average result, in addition, this test is actively developing encoders, when the results varies very much with each build or do not make sense, for example certain builds JXL lossless were several times slower or lossless WP2 is still very slow for practical use Also, the encoding speed is very different on different configurations and the use of multithreading and SIMD, also to fully perform all such tests on such a large number of images will need about a month of CPU work at full load (but it is possible to use small set, although I noticed that on some images Webp2 or JXL can be very slow and the results on small sets can be very different)

I think for lossy jxl, encode/decode speed is relatively mature (there is still room for improvement, but not a huge amount imo)

For lossless jxl, nah

Problem with lossy is that it's a lot harder to produce uncontroversial benchmark results

Either you do a real subjective test according to the recommended methodologies, for which you need human test subjects, controlled environments, etc, and then you get some results for a handful of images and codecs...

Or you use objective metrics, but then you immediately hit the problem that the metrics disagree with one another and it all boils down to which metric you believe.

If you're not pissing anyone off, you're not doing it right.

Of course, that doesn't mean that if you're pissing people off, you are doing it right.

Also, when I was testing PNG optimizers, it turned out that even the compilation options sometimes have a noticeable impact on speed and my test had claims that I used them for open-source optimizers, but for closed-source it is impossible and therefore the results are unfair However, when the encoders of the main formats will be relatively stable and optimized, I will try to add a comparison of the encoding speed, at least some approximate

Anything that makes anything not look like the greatest thing in the world will be controversial to at least some people

```poe.bmf 23 036 poe.avif 523 526 poe.paq8px202 14 036```

<@456226577798135808> yeah, indeed, now I got told “it's the noise which is actually fake, even analog one.” https://www.reddit.com/r/AV1/comments/n4si96/encoder_tuning_part_3_av1_grain_synthesis_how_it/gx6b7sf/?context=3

Funny, they don't seem to understand grain synthesis replicates the original noise <:kekw:808717074305122316>

Lol they're talking about replacing noise with detail with neural networks

I sure wonder where this detail comes from

<:kekw:808717074305122316>

"Potential noise should be denoised with neural networks like it is with ray tracing"

I fail to see the connection with denoising in video game rendering and denoising in film

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

Hm, sets with game assets would be interesting to add, but in practice it is very rare to use PNG or some other Web formats and mostly it will be Pixel Art games or these images will be the same as the usual art or photos (such as loading screens), the rest will be assets for textures and there are using GPU formats Unless there are UI elements, but for that I wanted a separate UI set

Hm, I have over 15000 lossless game screenshots. Atypical? Maybe. Relevant? Surely.

i think some games store textures on disk in an efficient format and then convert to a gpu format upon loading

<@!111445179587624960> do you still have the script(s) you used for that comparison? i could try on some game textures maybe

Yes, I still do not understand why these are irrelevant sets for the lossless test, these are not my images, these are various popular images from the internet that are everywhere, also I do not think that the main use for the web lossless format is game assets

It's not really scripts, maybe some cmd files (but nothing interesting there, just options for encoders)

for big 3D games that weigh dozens or hundreds of gigabytes, GPU texture formats are typical for most of the game graphics (exception being some UI elements and other 2D stuff)

for smaller casual games for phones/tablets, where package and install size matters more, png/webp are typical

For big games it's mostly specialized lossy formats for textures, including mobile games, but if it's some kind of 2D games, it mostly looks like Pixel Art or normal images or some kind of UI elements, except that they usually have transparency

9% is not bad given that the other formats in that list already had browser support (by default, not behind a flag) while jxl didn't even have behind-a-flag support back then. Why would any web dev doing image optimization even consider a codec that doesn't have browser support yet 🙂

yes - might be good to test more stuff with transparency (and also for cjxl to get an option to do invisible pixel thrashing in lossless mode and/or premultiplied alpha, still need to do that)

Yep, I'm still waiting for those options

https://twitter.com/NetherworldPost/status/1387634338859298817

<:SadOrange:806131742636507177>

I aree with market aggresively

Wb added random aut to the server to get more promotion

Random Not Most are in av1 server

But other joined

But you re right They are Not obliged to try JPEG - XL

Discord is still marketing remember

Unfortunately, I don't think the lossless comparison refutes the Blobfolio article, since the article was about lossy.

No he insulted also the lossless compression

He fails to provide his cli options then he says our data is "not representative" when we provide him data that's spanning thousands of tested images

I think he has his opinion and it's not going to change

He uses his subjective encoding app, which targets the lowest size, I think maybe he isn't realizing the artifacts of avif because of smoothing

He also fails to address the uses of modular lossless and lossless jpeg recompression

Which pascal?

Pascal knows what is doing

He's a dev

I never mentioned a pascal

did I mention already how much I hate the PSD format?

No, if you know anyone who can make one, I would be happy to assist them with the jxl side of it

We do have half-assed PSD input support in cjxl, mostly as a way to test multi-layer image input, as well as exotic stuff like CMYK and spot colors

Yeah, I'm more about this article spreading and people jumping to conclusions that the format sucks, without any of their own comparisons, as well as the title of the article itself

And for lossy and low bpp, as I assumed and asked to pay attention to this also in Jpeg XL back in the beginning of development (even considering that higher quality is much more important), people very often compare formats/encoders on low bpp and with time there will be more and more such articles

Also I think lossy WebP is just as good and sometimes even better in this article, because it is more tuned for non-photographic images and compared mostly on them and lossy JXL still needs improvement in this direction

Webp hits better vmaf with more than 50% jpeg input reduction

Like get better than this is difficult

Because jpeg xl cant even recognize a mozjpeg q77 jpeg

Also with webp you get a bit of Black and White

People also want small sizes at all cost

They arent willing to do this

Or to try lossless

They want 23 kb 47 kb Not average 80 kb and some 65 kb 55 kb

People also want one settings fits all

They dont want to switch encoders

They also want a low RAM mode one : both for decoding and especially for decoding

In avif as Long the speed of encoder is acceptable they wont complain

https://discord.com/channels/794206087879852103/794206170445119489/807906085239128095

<https://encode.su/threads/3002-Is-encode-su-community-interested-in-a-new-free-lossy-image-codec?p=69613&viewfull=1#post69613> **Raphael Canut ** > Just a quick note, some people told me in the past that I must adapt NHW to any image size else nobody will consider and use it.That's certainly right, but again I am working on NHW on my spare time and this task is too exhausting for me.Also, I feel now that it is useless, as I have read that in the very next months, the great AVIF and JPEG XL will be definitely adopted everywhere on the Internet. > > However it would be great to find someone that could take over the NHW Project.Turning it into a video codec for example, because there was interest in NHW for a MotionJPEG replacement, because a company was considering MJPEG for low-power camera devices, and MJPEG was too heavyweight for their processor (dual-core 240MHz Xtensa LX6, if I remember correctly).For now with rough calculation based on the latest Independent JPEG Group (IJG) C source code, NHW is 1.5x faster to encode than JPEG (and 2x faster to decode), but with switching off heavy processings with very few quality loss, NHW can be 2x faster to encode than JPEG and with a notably better quality/compression.This engineer told me that if NHW will be 2x faster to encode than MJPEG (and with a better quality furthermore) then this could be very interesting for such embedded products.

It's always sad when any of the new formats stop developing, especially not many wavelet codecs exist, but it's strange that in 15 years there was no attempt to adapt an encoder for images larger than 512x512 pixels, in my opinion this should be one of the priorities and then optimize speed, quality and everything else

Is it possible maybe in future to make jpg file sizes smaller than packjpg do?

There might be some ways to slightly improve jpeg recompression. Not hugely though.

We do have other advantages over other jpg recompressors like packjpg or lepton though: the jxl can be decoded progressively and in parallel. This is not the case with e.g. lepton, which uses AC to predict DC, making it inherently non-progressive.

ok

Yes, need to fully decompress before it can be viewed.

<@456226577798135808>it`s not a problem if you need to archive pix, there are plugins for viewers

<https://encode.su/threads/342-paq8px?p=69628&viewfull=1#post69628> > It's rare that I publish modifications around a specialized model only. There is a reason: with this version paq8px will most probably reclaim spot #1 in Lossless Photo Compression Benchmark.

🤔

Interesting

I wonder if some of the ideas from paq can be 'ported' to jxl encoder improvements...

<@456226577798135808>too slow for what?

I assume different trade-offs are possible, but usually I see ultra-slow, very dense compression results with paq

yep!

ignoring jxl-art, there's at least one case where a more-or-less exhaustive search produced a file 2% smaller than -s 9 (in two days, for a 64x64 file, but...)

I have a couple of ideas for a better tree learning algorithm, but I think they'll be super slow 😄

Slower is certainly possible 😂

Denser probably too 😁

snail has been suggested

glacier and tectonic_plate have also been suggested (not animals though)

Me

Plaster worms move very slow

Easy to find animals slower than tortoises in absolute speed: just find smaller animals

sponges are pretty slow too

What about sea anemones?

Looking forward to amoeba speed

It would be cool if we can somehow get the existing speeds for lossless faster, anything but s3 is quite slow atm

> Total runtime: 326266 sec (90 hours = 3.7 days) About paq8px speed Other encoders/formats, even the slowest ones are much faster, plus PAQ consumes a lot of RAM (although consumption is the same regardless of content and depends only on compression density options)

<https://www.reddit.com/r/AV1/comments/n7xrsp/does_gimp_avif_plugin_allow_lossless_compression/>

I remember a image format in which you can encode certain parts of image at higher quality and other areas at lower quality by specifying a mask image to the encoder. Anyone remember it?

Maybe I did implement that for lossy flif, not sure

Yeah I think it is flif !!!

It's certainly possible to do that with jxl too, we do need to add an encode option for it because it is quite cool

Instead of setting a global dist target, have a min-dist and max-dist and a heatmap where 0 means min, 1 means max, in between means in between.

DC would (probably) still be done at the min dist

But AC quantweights could be adjusted

Then connect it to AI saliency heatmap generation, and you get semantic variable quality where you do the bushes at d3 and the faces at d1. Not really a very honest / high-fidelity thing to do, but could be great for some web use cases...

I mean, adaptive quantization kinda tries to do that, but on perceptual level instead of "semantic" level...

Yes - and it wouldn't be interesting to just use the semantic heatmap as is as the quantmap, it should still do perceptual weighing. But the perceptual target would be variable instead of global.

Oh i see you speak also about variable quality in picture 😄

Look at this google map jpeg artifacts, it's a custom jpeg encoder? (it can be sensor banding, but i'm suspicious) I like these type of artifact against 8*8 bockiness.

Encoder is so optimized, we don't see horrible 8*8 alignment dct, but bpp see to be very low.

I answer to myself, google map use tiles 256px, i see size seem to vary to 0.6 to 1.9 bpp it's not very low as i imagine. It's the big noise of satellite sensor who "upgrade" de quality of artifacts of jpeg encoder. But encoder seem to be very good. That's a downloaded tile from maps.google

Artifact is a problem only on smooth area, when bpp is too low for jpeg.

And 256px jpeg tiles are not visible each other.

So, is lossy JXL faster in terms of decompression speeds vs PNG?

I doubt it - PNG decoding is not much more work than unzipping a ppm

well, could be faster for a large enough image and enough many threads

what you think about basis?

https://github.com/GoogleChromeLabs/squoosh/pull/1017

is it better than jpeg xl?

I believe Basis is used for storing graphics for video games in graphics cards memory. Don't think it's meant for the web.

lossless don't seem lossless to me

Texture formats aim for something a bit different than regular image codecs: it's to save video memory by letting the gpu use the compressed representation directly.

They are very fast and hw friendly by design, but not very great in terms of compression

why jpeg xl don't cover this use case

Not meant to. It's meant as a web format.

Well not just a web format. But not a gpu texture format.

why but not more I want jpeg xl for audio video and docx ?

at least add vector graphics support

_hides_

18181-5, Vector Extensions?

https://github.com/facebook/zstd/releases/tag/v1.5.0

We're getting them with every patch. We just get used to it 😛

JXL can be built with GCC, but knowing that Clang is now a bit faster for image encoders now, and that only modular would really benefit from faster encoding, I don't think using GCC has any benefits.

Re all, how to losslessly convert animated gif to webp and mng?

ffmpeg -i foo.gif foo.apng should work

<@!794205442175402004>thanx

mp4 quality on youtube is not bad

false

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

mp4 quality is heavy limited

but anyway tv use mp4

and i expect famous people get better mp4 quality

mp4 is container not codec

for that video the mp4 versions are h.264, but youtube also encodes av1 in an mp4 container on some videos

Does JPEG (1992) support wide gamut? (Probably yes, via ICC, but I just want to be sure).

yup, although you only get 8 bits, so...

Someone removed some bullet points from plwiki article and I'm writing discussion entry on that user's page.

```- Improved functionality and efficiency compared to traditional image formats (e.g. JPEG, GIF and PNG); - Support for both photographic and synthetic imagery; - Graceful quality degradation across a large range of bitrates; - Support for wide color gamut and HDR; - Royalty-free format with an open-source reference implementation.```

8-bit is OKish for P3, but I wouldn't do wider gamut than that with it

I agree that this info shoudn't be removed from the article. That user should have discussed the removal first.

<@!792428046497611796> <@456226577798135808> discussion entry is ready. Let's hope that they respond quickly... https://pl.wikipedia.org/wiki/Dyskusja_wikipedysty:Kubahaha#JPEG_XL

I tried to keep the tone quite cool & chill 🙂

I found something funny, <@!799692065771749416>

https://sneyers.info/jon_old/papers/jpif.pdf

a never-published draft

of something that would later become FLIF

that pdf is from January 2012

Jon and Pieter's Image Format, haha

it's a pretty early version of FLIF, it does some things completely differently

like that recursive splitting thing - that's basically an extreme form of variable block sizes, where things are almost completely arbitrary, a performance nightmare lol

I don't like the HEIF container

it's verbose and ugly

and Nokia claims patents on it

and it cannot really do anything we cannot already do natively in a jxl codestream

very good question, I have asked that a few times but never really got an answer other than a general feeling that Nokia's patents are bogus (which is probably true) so you don't have to worry about it (which is probably not true)

not really, other than that libheif could relatively easily add avif support by just switching out x265 for libaom

we still need to implement metadata handling properly tbh... we have defined brotli-compressed exif/xmp but we don't have tooling for that yet

well I guess there are two options: tricky and compressed, or convenient and simple but uncompressed/redundant

if those photos contain a large amount of exif stuff, probably yes

slower: probably we should let the brotli encode speed be configurable, fast brotli should be unnoticeably fast, but yes, at effort 11, Brotli encoding of a big exif/xmp blob will take some time...

yes a jxl will be always 22% smaller on camera

depends on how much stuff there is in the metadata, usually metadata should only be a small fraction of the total size

The http://cdb.paradice-insight.us/ website is down ☹️

If you want encoder have butteraugli support, I think only jpeg xl vardct have full support, libaom avif tune butteraugli only implement 8bit ycbcr. ```"Only 8 bit depth images supported in tune=butteraugli mode."); "Only BT.709 and BT.601 matrix coefficients supported in " "tune=butteraugli mode. Identity matrix is treated as BT.601.");```

I think maybe someone will need this information.

<@!111445179587624960> have you recent result of lossless webp2 with 19052021

even a small benchmark comparison?

could you link me the discord link?

No, I'm waiting for some major changes, because the encoder is very slow

is very fast in lossy

s9 is max 1 minute and 30

with hd image

on i3 330m

not even a avx2 processor

lossless is slower?

even of how it was lossy before?

in my experience it's faster than avif but not as fast as jxl

like 2 hour a photo

In lossy yes, unless using the slowest speeds, but on lossy there are comparisons from the WebP team

At maximum compression Lossless WP2 is 5-12 times slower than JXL

what are you saying

that like on i3 330m with a month old wp2 version

3 hours for a wp2 hd in lossy

21 hours for a wp2 hd in lossless

lossless is more complicated

?

is really true do you have done extensive testing with your hardware?

also now lossy takes 1 minutes and 30 at max speed

lossless is still many hour range?

.....

but i cared about the compression

how it is

can you link a discord link

of an image that does similar like a screenshot from a phone

not computer screenshot please

I have done tests for WP2 and they are in my comparison, but it is not the most recent version (I don't want to do new comparisons very often without significant changes because it takes a gigantic amount of time) <https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/>

no i want a link in benchmark

and not with pixel art please

or i will do when my phone is charged

i will benchmark one screenshot

what i should set

-effort 9 -q 100 ?

or other options?

This is a lossless benchmark for all types of images, for lossy there is a comparison from WebP team and eclipseo (but also not the latest versions) Yes `-effort 9 -q 100`

thanks

webp2 still use PSNR? I can't find some information about this...

Just use Butteraugli and/or SSIMULACRA lmao

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

Originally in FLIF we had the same idea, just not with neural nets but with MA trees. Define deterministically how the tree gets trained during encode/decode, and you don't need to signal the tree itself

We ditched that idea because it implies slow decode and also no way to later improve the encoder (since the tree learning is part of the bitstream spec, not an encoder choice)

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

`hexo 1 day ago` > Sometimes I wish people programmed like we had 512megs in a luxury machines. God I wish... *Twenty One Pilots: Stressed Out starts playing*

limitations are better

nowadays we have 400GB AAA video games

look at the demoscene with all their stuff fitting programs into the tiniest sizes

ofc that's not realistic but like 10-100x less space efficient than the demoscene stuff and you have a program that's already smaller than most things available as of now

They spent all the budget on actors and artists, no money left for coders?

(I think they also secretly think "more gigabytes" means "more game" or "better game" or "worth more")

CDPR spent all their money on ray tracing and Keanu Reeves and that's why CP2077 is buggy, makes sense

164 vs 14.1 kb

compressed image

in 720p av1

set q 70.9

webp still good at compressing

so that's why people don't use jpeg xl

But I think most of those are textures and the like, no?

it's kind of the same to me

settings for wp2

blatant use of raw textures is very similar to not optimizing code at all

notice that even at high quality it starts to ruin detail

you could use zopflinated PNGs for textures

long compress time but speedy decompress time

perfect for a video game

especially when you would have used raw textures

well, the problem is that textures typically get decompressed by a GPU

and they don't like PNGs

hm

basically it would increase game load times AFAIU

there's tons of gpu friendly middleware formats

i guess that can cost money

but if i was developing a game i'd do what I needed to to not have raw assets

https://github.com/BinomialLLC/basis_universal

Welp that's a free solution

No reason not to try it

Uncompressed assets are so lazy IMO

Maybe games should look more into procedurally generated GPU textures. Something like jxl art but not restricted to an existing bitstream, any code could be used. That would be even better than any compression.

I think demoscene does this

Yes

In the future when procedural generated worlds are more common

We could get fully procedurally generated textures etc

I know games like no mans sky did procedural generation, but even that game had set textures and other things

It's of course harder for artists... You don't get a paintbrush, you get tunable parameters or just writing code

Very different paradigm

It would be a modern achievement to have a fully procedurally generated realtime playable game

That didn't just look like randomness everywhere

https://jxl-art.surma.technology/?zcode=XY7BCsIwEETv-xVzL4FtIh4FFbQnFRVyLmZt99BWavD7TaJ48LLMvmGG2WgM8og9aiavoQi7oEa06-NHH2eVMbZRpxE1nbfXdHdzO8hpeoJhHDMR6R03rJJlcJEIY_nH-Mucc4X5xJYpBBisX52vDqkkfdnaNyWA7PkyQgIq-09y_Rs

That could be skin

https://jxl-art.surma.technology/?zcode=rZDNCoMwEITveYo5K8EotXgqtIXWk5W2kLPUqAF_igahb9-NVLD35BB2duHbnTlpU6q3aRCGTOrSFiLawc1Lla4bsxDZbdSqN4XRQ4-Q3c9P-i9j0al8mCDAQyEY0xVeONAk8NDo3mCo0A3TBC-wsw_N9kI4uo6AeT6qmaAxLf_xE2d8juNcZ34m4SNmWxWReigbjNhUq_u1584pLFoSmscOw7NAulswa1WCJ7ay_Wu6uFgjOLYtBfwn-aolIgJ8AQ

That could be used in a tree

`stat -c "%s %n" 16* 117391935 16.emma 96327187 16.ppm` <@!111445179587624960> I tried to compress a dng data.

Maybe this EMMA does not have a parser/model for DNG, perhaps it is better to use the older and complex version (but this is a general compressor for different formats, not an image format): <https://encode.su/threads/2459-EMMA-Context-Mixing-Compressor>

The ppm contains what? Grayscale bayer data?

After using it on bayered data, it compresses better.

Imagemagick ➡️ dng to ppm; emma ❎ dcraw -D ➡️ pgm to ppm; Emma ✅

Uncompressed dng - 30.7mb Emma - 4.8mb

ppm - 45.9 mb

Just 4.8 mb raw data 🤯

Jxl modular s7 - 7 mb

zstd -19 - 8.6 mb zpaq -m6 - 5.5mb

how about `-s 9 -E 3 -I 1`? (be prepared to wait for a *while*)

bayered data as grayscale is probably not very good in jxl, better do it as 4 channels. We have an extra channel defined for bayer deltaG, just nothing implemented that uses it

4 channels? How to do it?

I guess we'll need to write a codec_in_out that can take dcraw pgm as input and reconstruct it, for flif I did some stuff that did that

It's taking more than 10minutes. I stopped it.

haha

we'll do that for lossless too someday 😛 (it's mostly an encoder choice)

https://github.com/hohMiyazawa/deebtjeme

https://github.com/ceynri/FIC

That's cool but also the most niche image codec I have ever seen

Where's my cat compression codec?

This is how my cat was sleeping yesterday

Head down

https://www.livescience.com/cats-tricked-by-optical-illusion-boxes.html

https://github.com/AOMediaCodec/libavif/commit/2a639cac34ee7881f07ff685b8faa43073799b66

I think it's a bit wrong to call this "progressive AVIF"

I would call it either "AVIF with a preview image" (if the preview image is independent of the main image) or "Hierarchical AVIF" (if they use an AV1 with multi-res 'layers' which do the "upsample previous version and add residuals" thing.

the relevant analogy is not progressive JPEG, but either a JPEG with an embedded Exif thumbnail, or a hierarchical JPEG (which was a thing in the original JPEG spec but nobody really implemented it and it doesn't really work well enough to be worth implementing)

These are three different ways of doing 'refinement steps', but they all work in different ways: - A preview is separately encoded and could be a completely different image than the main image. - Hierarchical encoding first e.g. encodes a 500x500 image, then a 1000x1000 residual image that gets added to an upsampled version of the 500x500 image. So you do need the first image to decode the second, but you're still encoding extra pixels (and in practice in JPEG this approach doesn't work well because encoding the 1000x1000 residual image is about as costly as encoding the 1000x1000 full image, so you are basically doing an extra encoding of the 500x500 image, meaning the overhead in density of doing such a thing is very significant, since you are kind of encoding pixels multiple times (or put another way, for every 4 pixels, you essentially encode 5 pixels, and the extra 5th one has more entropy than the other 4). - Progressive encoding encodes the final image with a bitstream organization that allows extracting lower-resolution or lower-quality previews from prefixes of the bitstream. No pixel is encoded twice.

As far as I understand, AV1 cannot do progressive encoding. It can do multi-layer encoding though, which is a form of hierarchical encoding. And at the AVIF level, you can have previews.

JPEG XL can do previews, multi-layer, and progressive encoding. Its lossy mode is _always_ at least somewhat progressive (1:8 goes first), and can be very progressive.

These subtle differences between preview encoding, hierarchical encoding and progressive encoding get a bit lost if we just start calling everything "progressive", imo.

<@!321486891079696385>, again quick question: will VVC support grain synth like AV1 or not? I don't want VVC not to have it (because unfortunately I doubt that AV1 will end up in cable TV decoders)...

Technically, there is an Supplemental Enhancement Information for grain synthesis, but the way it's done inside of VVC seems less complex and complete. But yes, it does support it if someone were to make something around it.

Procedural textures are already possible - but doing it in game is trickier for performance, you would probably need to do it at launch time.

<@!321486891079696385> one last (at least for now), very important question: There's that June 1st Google Photos free tier apocalypse. JPEG "High quality" transcoding in Google Photos can *really* suck sometimes, so I think I'll store my not-yet-converted photos in original quality, taking up space (and convert them inside Google Photos to JPEG XL, when they *finally* ship it). The main problem are **videos**. The originals are big and I'd go bankrupt the very moment I wanted to store them uncompressed on Google Photos. Unfortunately their video transcoding in free tier *butchers* video quality more than pictures, so I'm thinking about two options: - upload in free tier and accept mediocre video quality, but at least they'll be stored for free, - wait for PCs to get more powerful and encoders + stabilizers to mature and *properly* stabilize them with AI that doesn't get jerky and doesn't lose field of view (second one being my biggest complaint about Google Photos for Android built-in non-AI stabilizer) and then encode with a mature AV1 encoder with grain synth and personalized parameter settings (the BIG downside: I'll have to store those videos at full capacity). I'm really concerned about video quality, but at the same time I don't have stable budget. If I drop out of my uni (something quite likely to happen) bc I'm stupid, I might actually become homeless. Which option would you choose?

<@!111445179587624960> do you know if BMF can do grayscale?

Yes, except that the alpha channel is not supported, otherwise it is a typical image format

The 1st one is your best alternative.

But some videos are *completely* shaky (they were taken either with a smartphone or with Nikon Coolpix P900 at high zoom settings). Are you sure that it's better to just upload them all without any offline backup and processing? I thought that AV1 can compress quite well without that much quality loss...

x265

HEVC doesn't have grain synth...

Is grain Synth necessary for videos taken with p900 and smartphone camera? I think finer details are already lost with those cameras.

Maybe not with P900 or Samsung Galaxy Note 9, but Lumia 950 will *definitely* benefit from grain synth because of less destructive, more "natural" processing.

A good solution is to upscale in 4k your video (fast) and then upload on youtube/google. Bitrate is acceptable.

Hmm, strange, when converting LibVips to PPM not all encoders understand this PPM and also the size of the resulting encoded files is larger (with IM or ffmpeg this does not happen), I found only this difference in these PPM: ```#vips2ppm - 2021-05-31T19:31:32.569078+03```

What is the first line of the PPM file?

It's a comment in the ppm

Maybe some encoders keep the comment in metadata

Something like this, but IM and ffmpeg do not have this comment: ``` P6 #vips2ppm - 2021-05-31T19:54:10.760181+03 717 1000 255 ```

strange, decoders should just ignore the comment

There are quite a few lazy ppm readers that don't properly handle comments

Yep, but especially old encoders or something like EMMA don't understand these files or the resulting files will be larger So for more accurate results, I am forced not to use LibVips

Doesn't it have an option to not write that comment?

<@310374889540550660> ?

In general I don't really like encoders that leave traces of what encoder was used and when it was done - that can be useful, but it can also be a privacy issue

Try: ```bash $ vips copy x.jpg x.ppm[strip]```

No, nothing has changed

Ah, yes, that's a 8.11 feature (RSN). See <https://github.com/libvips/libvips/issues/2245> and <https://github.com/libvips/libvips/commit/970ba8cfcc84d83c65687acd64192b3f9121b7b2>.

Vimeo is now using AVIF https://medium.com/vimeo-engineering-blog/upgrading-images-on-vimeo-620f79da8605

PSNR <:SadOrange:806131742636507177> (however, with other metrics the difference could be even bigger)

Hm, WebP encoding faster than Jpeg? So for Jpeg something like MozJpeg was used and WebP was not encoded at maximum settings 🤔