JPEG XL

What options?

`-e 9 --photon_noise= (and here the values can be different for better results)`

but even encoding with the default settings is not much different

And that's a very far thing from quotes like this: > For lossy color data use AVIF (significantly beats all older formats like WebP and even JPXL for almost all settings) > JPXL works very well for reducing the size of existing JP data without having to reencode (and lose further information) other than that it cant compete with others in lossless or lossy mode. > In my own tests (which i do alot of) at their default settings AVIF gets files to MUCH smaller sizes while still appearing visually lossless. Also about lossless: > For me a file is either 'hot' in which case I don't need great compression and just want fast decode (in which case LZ4 bitmap is unbeatable) or a file is cold, in which case I was either the deepest lossless or lossy compression. > > JPEGXL will never compete with raw or LZ4 compressed formats for speed and it's minor compression advantage for hot files is just not significant enough to make me use it. never compete with raw formats for speed? 🤔 minor compression advantage? 🤔

I mean, when it requires such a high decoding speed that almost any compression is unacceptable, it's a very niche use As well as the minor compression advantage over raw data This is a very large gap between the maximum possible compression in any amount of time and only the maximum possible decoding speed

Also why bring up LZ4 on a post about archiving. You probably have the time to compress it better.

I think it means fast decoding

However, image-specific formats can be much faster and more efficient than using LZ4 on RAW data If speed is so important, for example for textures, there are usually some hardware methods in the GPU (mobile as well), hardware compression/decompression in modern game consoles, etc.

Probably we can use some anime, 2D drawing, manga, comic image set become a non-photo standard testset for compressor performance test? > http://www.manga109.org/en/ > and Scope lossless compare sheet

Good test sets are useful, very often test sets only include photos

It is still not very convenient in terms of use > When using parts of the dataset within academic papers or videos, please note the author’s copyright notice as “© Author’s Name” and note that the work was cited from the Manga109 dataset. In addition, for use in academic papers, please cite the related papers shown below as well but probably better than nothing, especially if the quality of the images is acceptable (not some bad scans and exJpegs)

I am co-chairing a new jpeg AhG called GMIS, which is looking to do something related to multi-image use cases, e.g. multi-page comics

We are now looking for test sets (i.e. sets of sets)

Copyright notices are OK I think, just need to collect them properly. More importantly the license does need to allow any kind of use, not just non-commercial or something.

It's most convenient if it's CC-BY or something like that

> under the condition that it will be used for academic purposes at non-profit organizations, for research-related uses such as experiments and publishing academic papers

my issue with manga109 is that it doesnt contain anything from the current moe generation

wouldn't a good image, be pure raw png, comprising of 4 different core types of image. IE top right corner is say manga/cartoonistic, bottom right is fractal, top left is a photo with moderate photo distortion, bottom left is then a hi range rather abstract image.

That's a problem, e.g. Cloudinary and Google are not non-profit oeganizations

that way with one image you can quickly reference a codecs ability to encode different forms of media, and different quality senario's

only issue would be if its block encoding, the edges between the different sub images

And the downloads are not freely accessible and require asking for a password (also Manga109 contains comics which are approximately 40 years old)

It's quite rare that a single image has such very different types of content, and it is likely that lossless encoding of the composite image will be worse than doing it as separate images.

`lossless encoding of the composite image will be worse than doing it as separate images` What about lossy encoding? slight lossy but not mathematically lossless.

Nice! But can't this already be done with JXL? ^^

We have multi-frame/multi-layer in jxl, so it could be a potential payload codec for GMIS. GMIS is more about the metadata/container info of how the different images are related and stored with payload codecs

Hmm, from what I could find some manga109 examples, these are mostly ex-JPEGs with typical artifacts <:SadOrange:806131742636507177>

It's really hard keep all image on lossless format, even in 2022 still can find a lot of manga use jpg, I understand lossless is great, but I hope jxl can implement some slight lossy method for non-photo content.

lossless jxl works for me

yesterday i got more than a 60% reduction on a doujin in png

lossless music is fine

lossless hi res music is dumb

Btw, what if use `-e 9 -E 3 -I 1 -g 3`, of course if the encoding time is not that important, some disadvantage of `-g 3` is that less threads will be used to decode a single image, but for browsers and manga there are usually many other images for parallel decoding Otherwise, I got better total compression for manga content with such settings

i currently only have -q 100 -e 9

and i view the images on my phone so it's at most decoding 2 images at a time

One regret I have is not pushing for a -g 4 or higher, the bitstream is limited to -g 3 but parallel en/decode is not useful in all use cases so it might have been better not to force a max group size of 1 megapixel

Jxl2 when? :p

I think this is also acceptable for the phone, because it's just a larger group size, so there will be less groups/tiles per image, but with enough resolution it's still fairly enough

yeah i'll try it on the one from yesterday

There's always a tension between making the bitstream as expressive as possible (for better compression) and making it as non-expressive as possible (for faster decode)

oh my

1 MP group size means multithreading is still going to help as much as with the default 64 kilopixel group size, if you have an image that is [nb of cores] megapixels

Yes, I also wanted to suggest such a feature when the format was not yet finalized, as I remember WebP2 also uses tiles, but they can be the size of the width of the image or something like that

Then again having a _guarantee_ that parallel decode can be used is nice to have

Also puts an upper bound on the memory needs of a decoder

Btw, how difficult is it to change the group size in FJXL code for the tests, I think that if the compression is not much worse, like 1-3%, then using the smallest group size and therefore increasing the number of used threads would also be good for even higher speeds or it also affects the optimization and SIMD or something else?

It is also better to do the comparison on some set of images rather than just a single image, because the compression is usually better on average, but may be worse on a specific image

im doing it on the 50 pages from yesterday

Then it's good and also better if these images are not from the same manga

well it's just an apples to apples comparison

Not very hard at all, just need to change some 256 in the code to 1024 and adjust the header that gets written

Btw talking about manga... https://twitter.com/MichaelDBruton/status/1486741220751814656?t=zFwspQz8p27CXeAG2-kQDg&s=19

Will be fun when I have to renew my passport

So maybe I can make these changes in the code myself, although it might be useful to have this option in FJXL if it doesn't complicate the code too much

in total 80984 bytes smaller, 38443379 -> 38362395

And if without -g 3, but with other options?

Larger group size is not necessarily better for compression, e.g. in fjxl, the RLE can be multiple rows, and you might get longer runs with smaller groups than with large ones

And in slow cjxl, local palettes can be better with smaller groups than with larger ones

Should be easy to make it a compile option, probably a runtime option could be done too but not sure if that would affect performance

Yes, that's why I wanted to decrease the group size for FJXL instead of increasing it, to make more threads work and therefore faster encoding speed

How many cores do you have?

Because a 1 MP image is already 16 groups with the current default group size

There are 8 for now, but it may be possible to access up to 32 And these are just theoretical tests to compare how much compression can be worse or it does not really affect

Also: the palette detection and huffman code sampling is sequential, and I can't think of an effective way to avoid that for palette detection

(one thing perhaps worth considering is doing palette detection per group and doing local palette instead of global. That would of course parallelize easily)

Will it have a small effect on speed, outside of parallelization? Because it is also likely to be better for compression

-e 9 38443379 -e 9 -E 3 -I 1 -g 3 38362395 -e 9 -E 3 -I 1 38167988

Hmm, yeah, `-g 3` didn't help on these sets, I had the similar thing on some of the manga sets, but overall it improved the result by like an extra 5-8%, so it really depends on the content

But, `-E 3 -I 1` almost always helps, at the expense of some extra encoding time

Also decode time, for -E 3...

However, not so much compared to only -e 9, but, yes, slow lossless modes in general are still quite slow also for decoding, especially on large images even using multithreading (which is also not enabled in Chromium engines)

I totally agree jpeg xl lossless is great for non-photo content, 🙂 but for some use case, need use lossy method to get more compression, (high quality lossy, near-lossless, high fidelity lossy, but not mathematically lossless), In my test, av1(aomenc) DCT lossy mode and palette lossy mode on q7 s3, can get good compression for my non-photo test set and picture still look very good, but for some picture, av1 reduce too much detail and noise. jxl(cjxl) varDCT lossy mode is very great on d1.0~0.5 e8, can preserve grain,detail,noise better than av1, but I still feel too much tiny artifacts on specific area for non-photo content, and don't have auto palette mode to avoid DCT worst case. I think if jxl can preserve grain,detail,noise and preserve high contrast sharp edge clear on vardct, and have auto palette mode to avoid DCT worst case, that will be very great.

<https://github.com/BinomialLLC/basis_universal/wiki/Release-Notes> > Except for Zstandard, all 3rd party code dependencies have been removed from the repo to simplify certification and code licensing. PNG reading/writing is now handled by new code (pvpngreader.cpp) **instead of lodepng**, Android's ASTC block unpacker is no longer required to build the encoder (we instead unpack the UASTC pixels directly to 24/32bpp pixels), and BMP loading has been temporarily removed. it is strange that there may be some law problems with lodepng and wuffs and they are no longer used (because devs aren't from the U.S.) 🤔

Jpeg XL as well? 🤔

That image isn't in my default test sets, in any case.

<@!461421345302118401> look at the files youself

this s 7 new heusitics fom 24 janua

i used lates build fom today

is not cjxlng that is incomplete and nobody has compiled latest cjxlng fo me

brotlidec.dll is missing on my compute

this in nomal heuistics is exatcly 1 bpp

640 kb

I haven't find encoder quality tag Pull requests at 2022, maybe I miss something?

Yes there is an important ans improvement on 22th january

And on 18 january jaimaika on doom9 compiled cjxlng

That is incomplete

I'll advice to refuse svt av1 0.9.0 normal

There isnt bug fixed that it looks blocky on open movement

More blocky than closed One

And bitrate is like 756kb vs 1100 kb for complex HD footage

Use latest pipeline

On gitlab

There is m12 idfa

Idap

Is a substantial change 500 Lines of code for av1

Still It doesnt look Good perfrpmsncd wose

Note that "developed without Lena" is deceptively broad, as Lena was previously part of their test corpus. <https://github.com/phoboslab/qoi/issues/35#issuecomment-980522411>

is it really possible to have a codec "developed without Lena"? you're still drawing on knowledge from previous codecs that were developed with Lena

I think they are talking about other products of their company

I guess technically so. Still ironic. 🤷‍♂️

Meanwhile, in PIK there were FSE/tANS experiments/usage

🤔 <http://cbloomrants.blogspot.com/2018/10/oodle-lossless-image.html>

> Oodle Lossless Image is all about speed, but still achieves very high compression ratios - equaling or bettering WebP, FLIF, JPEG2000, and of course way more than PNG. > > But unlike other compressors that accept a trade-off for slower speeds, Oodle Lossless Image is still super fast - its decode speed is 5-10x faster than PNG and 200-500x faster than FLIF! It's just massively faster than anything else at these compression levels.

> > **fgiesen** > The speedup is mostly from replacing zlib with the Oodle codecs and some high-level changes to filtering to get more parallelism. The basic architecture is very similar to PNG, i.e. apply lossless filters then hand over to a LZ backend. The filters are the standard PNG filters plus a few new ones, namely 3 different types of gradient predictors (sorely missing in stock PNG) and a parametric linear predictor (fixed-point filter coeffs are determined at encode time and stored) > Images are usually chopped into independent tiles that can then be predicted simultaneously (regular PNG filters are very serial).

What is the parametric linear predictor, is it useful? Or does JXL have something similar or just as efficient and fast? Also about MRP (Minimum Rate Predictor) there are plenty of research papers about it, mostly for grayscale images, but currently it is not so actual?

However, Oodle Lossless Image is not easy to test and get, although it seems to be free for those who use Unreal Engine <https://www.unrealengine.com/en-US/blog/oodle-now-free-to-use-in-unreal-engine-via-github>

And as I wrote before, some mode for JXL with relatively good compression but very fast decompression would be very useful (I think it's possible to be faster at decoding than WebP, with the same or better compression, if consider using multithreading)

Yes, faster lossless decode should be possible, with some specialized paths for up to 14-bit and limited use of transforms

On the one hand it is interesting and PNG is already a common format, but on the other hand, perhaps it would be better to spend months of work and research in some modern formats, especially the game industry is not so dependent on standardized and common formats as the Web and the using of even some custom/proprietary is quite common https://twitter.com/richgel999/status/1487961655279591427

Although RDO can be useful for any format, but this tuning is mostly only for Deflate and PNG filters

But still, something new for old formats is always good https://twitter.com/richgel999/status/1487963294417760256

<:monkaMega:809252622900789269> https://twitter.com/richgel999/status/1488124880679755776

Free <:Thonk:805904896879493180> Also, I'm not sure that using copyrighted images, photos and arts makes them free after adding a transparent background

Yeah, but it's like, it's not us, it's users uploading copyrighted material

I also thought about using this for tests/comparisons, but, what I see doesn't look like CC/PD images

it does look like they aim for CC0 originals, not sure how thorough they check for it though

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

Also about suggestions from various people that JXL needs a different extension for lossless, because everyone knows that PNG is only lossless https://twitter.com/richgel999/status/1489594494748176385

Replied in that thread: https://twitter.com/jonsneyers/status/1489660057356804096?t=MzP7CRei1s6J-1aT42qFDw&s=19

I don't think lossy png is a particularly good idea. Interesting maybe, to see how far it can be pushed. And there is some compatibility argument to be made: it's still the only universally supported format that does alpha.

But any other modern codec will absolutely beat png in lossy encoding

A different extension for animated could be useful in case of putting an animated jxl through an application that only supports still images, (Although I know it would just use the first frame IIRC).

Can some kind of file extension/mime for multi-page jxl also be useful? Taking tiff as an example, it's a bit inconvenient to constantly have to switch between image and document viewer, as a few image viewers support multi-page tiff.

do you mean like an extension other than .jxl, or an extension to the format? i thought the format already supported multiple pages

Something like '.mjxl' for multipage-jxl

well, if motion jxl becomes a thing they might want .mjxl

but i think in general the extension is always .jxl, and perhaps document viewers could add support for jxl files whether or not they have multiple pages

isn't the idea that the jxl is tagged with headers for stuff like that

It's just people want to recognise jxl type without opening the file. It would be better on Linux to identify the jxl type and assign specific icon to single layer jxl and multilayer jxl. But on windows that's not possible I guess.

Even with different mime type it will require OS parse not only signature, but also pretty complex ImageMetadata header and AnimationHeader bundle :(

well it's not in the spec

so you will be making an extension/your own spec

as it always has been with jpeg etc

it's not like your custom usage of jxl will be supported by libjxl

and file extensions are just file extensions

your program and os better well be reading the headers

oh is multipage not in the spec? i thought it might be

idk about multi pages

i think there's layers

I think the layers serve dual purpose, either for animaiton or for blending (e.g. modular patch layer over a vardct layer)

animation frames can be used for pages

As I understood, have_animation: false && multiple frames => layers have_animation: true && multiple frames => animation have_animation: true && multiple frames && max frame duration => multipage

that mainly sounds like an implementation specific kind of thing

since it's not like my windows photos will support multiple pages

I mean, for that we just have 3 extensions that are all functionally the same. .ijxl .ajxl .mjxl image jxl, animated jxl, motion jxl. along with just standard jxl. all functionally the same, just with different extensions. the issue with that would then be, someone without relative know how wants to restrict say, animated jxls then you have the issue of them making a poor implementation, just restricting the extension of ajxl.

so yes, it would be nice to have windows properly display icons for all the different types. but realistically it won't really serve any benefit.

ontop of that, this can be something implemented by the user and not the standard. as it has 0 impact on decoding and encoding

i recognize the jxl type by looking at the filename containing the extension .jxl

as you should

currently my method of file detection is checking it against all supported magic numbers. then just returning a generic file not supported error for anything not found.

if there's no extension on an image, i drag the file into firefox to see if it opens

||APNG IS A FUCKING BITCH||

na, i use it for an image board. so extensions that I support but need special handling, that have 0 magic numbers are ... anoying

On Windows, shell extensions allow to show icons depending on file contents. For example, Visual Studio solution files show their Visual Studio version on icon, even though the file extension is always the same.

Animations can include series of zero-duration frames, which I'd guess is indistinct from "layers" here. Max frame duration to signal "pages" was just a suggested convention.

Telegram implemented animated video stickers based on VP9 with alpha channel somehow 🤔

https://telegram.org/blog/video-stickers-better-reactions

APNG is used for the same purpose by Steam and iMessage

But I guess VP9 must be more effective

Yeah, it's just webm files with alpha channel. Didn't know that VP9 supports alpha channel. Cool.

it's funny because VP9 Profile 1 is NOT supported anywhere as hardware decoding

it just lags on my smartphone 2018

remains only to wait for the support of AV1 and then we will gread live

although without hardware support we have only reached the Power to play 1080p HEVC....2013

telegram supports HEVC for a long time but I encode it only with the FASTDECODE key and level 3.1 (720p 30fps max or 540p 60 fps max) because otherwise Most smartphones Won’t Play it

how to optimize av1 This is problem the world is not ready

It works perfectly fine on my old 2014 PC, but yeah, it is a bit slower than expected on a smartphone

Probably, just bad implementation, and it can be optimized?

no

single videos work well

It should be okay for stickers. Lower resolution

but when the total videos play exceeds 2 megapixels, problems begin

a lot of stickers and gifs, for a telegram this is a maximum of 8 stickers at a time

it would be better if the size of the stickers was not 512 but 256 pixels

probably the decision was also made because in the VP9 codec size 512 is the minimum size at which two-theard encode and decode is possible

Does tg avoid re encoding when sending level 3.1 hevc videos ?

telegram does not change original videos at all

only if you're on a smartphone can you compress your gigantic videos quickly

low quality

So you mean, it doesn't transcode on tg desktop

doesn't transcode on all tg

I want to say that VP9 is a terrible format that works well exclusively on YouTube

But when I send videos on telegram on smartphone, it re encodes the file to x264.

the main problem is multi-threaded coding

what video are you sending?

Any vp9 and x265

if your video weighs a lot, it sets the default setting for its compression, because no one wants to download 200 megabytes for 10 seconds of 4k video from a smartphone

vp9 is of course not supported, but hevc... is actually a smart solution, because my smartphone will not be able to play 1080p 60 fps

but compressing in hevc is too expensive even with not the most minimal parameters

Your phone doesn't have vp9 hw decode?

my have

telegram have not

❓

<:Android:806136610642853898>

⁉️

i dont get it

I wonder if there will animated AVIF (just av1 non-sound)

dont you mean

just av1 without sound

but like gif

finally 0 kb gifs

what makes gif different from a video

sound

a

sound is completely separate

gif is video

today

in telegram any video without sound is a gif (10 mb max)

🤔🤔🤔

I just sent one video without audio. It didn't convert to gif.

Maybe it's just a naming, a lot of image hosting sites and even in Discord short animations are shown as GIF, but in fact it is H264 video or something like that

do not convert

gif is not .gif

Discord is outdated.

it still uses gif is .gif

because it uses what you give it

can you use mp4 without sound? no.

Discord will accept any chromium supported format with 0 conversions

it will also support any non-chromium supported format, but will only allow you to download it, with 0 conversions

what?

discord allows anything your browser will and it will display it. discord does not do any behind the scenes conversions or transcoding. as far as Im aware discord will however compress all uploaded files internally.

also gif is not in any means close to a video format.

the Discord just can't play it as a gif, although it's a matter of one fix from the developers, just like support for any new codec like AV1 or JPEG XL It's just that the developers haven't made any innovations for many years.

because they don't need to.

i need

and they dont support AV1 and JPEG XL because, its not supported on every browser

then do the conversion yourself

av1 now support in all

and avif

no it isn't

its no browser

again

AV1 is not supported by every browser

please google it yourself, if you still don't believe me.

and this is the reason that discord like quite a few other platforms still choose to not natively support it. as it would mean writing special case scenarios just for supporting browsers.

safari only

bruh

Safari is also every browser on iOS

Chrome and firefox on iOS are Safari with a skin

It seems that discord is used on smartphones Not through a browser

yes it is

discord is ran on what is called an embedded browser container

About the GIF, I think because it will replace stickers and Tenor (as their special feature), but, for example, this is a video (although shown as a GIF) https://discord.com/channels/794206087879852103/805007255061790730/939105391940354068

Probably same issue though: they're going to want to rely on Apple CoreMedia for image/video rendering

its in a sense the exact same as a browser, just with a few extra features on the js interface.

this is strange because they made API for mp4-gif only with Tenor

that would be something that happens on the server-side of things within tenor

And most likely the same reason why APNG and animated WebP features are disabled

animated WebP is stillborn

I have seen Microsoft use APNG on their websites

thats because its practically supported everywhere

But of course, Discord does not support it.

Does discord on iOS runs on safari ?

I'm pretty sure due to the nature of apng, you can just upload it as png and it will work all the same.

the point was, that only the browser needs to support it, not the platform

you have to open it in a browser for it to work

doesnt work on discord

that would be down to the embed container not supporting it then

the discord app runs on "electron JS" and compiles in its own mini "browser"

`discord/1.0.44 Chrome/91.0.4472.164 Electron/13.6.6`

its Electron 13

Electron is dated and bad

and I hate working with it

in theory, they could do an aggressive PR campaign by adding codecs to their application that are still missing in the browser... but they have not added absolutely anything since the very beginning of discord

but no, Electron does not support APNG

not in theory, as most of the time 1. no one cares, 2. its a lot of developmental work

(discord's stickers are apng/png)

christ the only reason i got into making the wasm interface for libjxl was so I can more easily make native jxl decoding in the browser

As I said, this is done on purpose so as not to compete with the paid and other (like a collaboration with Tenor) functionality, not for technical or other reasons

hahaha yes

https://media.discordapp.net/stickers/891173091802234920.png

that is, the developers simply banned another apng

Unlike, for example, AV1, because full support for such videos would require conversion to more compatible formats, which requires additional costs for servers and other things, so AV1 support is a technical reason

this is not a problem, no conversion is needed, just give support for the codec, and the users themselves will use it

everyone can't wait to compress full anime series into 8 mb for one series

(if you have a threadripper)

This is a very small percentage of enthusiasts who really need it, most users are more concerned about making sure everything works properly or they will be angry and spam the support about why some videos do not work

vp9 doesnt work on ios or mac

and they dont convert it

I think it will be easy to make an inscription that the video is not supported by the browser, but most users still sit from the application on a PC or smartphone

VP9 is a much older format, I don't know about Discord, but Apple said they added VP9 support at least for YouTube (so theoretically it's supported)

yes, and it doesnt work on discord

just like hevc doesnt work on all platforms on discord, but does for some

do they convert it to make it more compatible? no

nobody converts anything

keep vp9

Discord does downscale uploaded images (poorly btw, it ignores icc profiles and assumes everything is sRGB)

yes for preview

I would like the previews to be in avif format

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

I do not think that these speeds are really needed, but I guess it is possible for JXL, something similar to LZ4 (for example LZSSE even faster and denser) or even if take some Huffman variations, they are slower by less than 2 times, which is also pretty fast Perhaps it was also worth keeping Brotli for pixel data compression as it was before, or does that not make sense when LZ77 was added? Pure Brotli isn't really effective for image/pixel data, but if using just some parts for experiments, maybe it would make sense

Also, this is not the first time the LZ4 has been mentioned as something unbeatable in terms of speed

Btw, I have a gigabit internet for about 10 years, but I'm still worried about the size So again two polarities, some people want maximum compression even for lossy and something like AVIF or even AI codecs is the most needed evolution of formats (even with a significant difference from the original, but if they look pleasant), others don't really care about good compression even for lossless <:Thonk:805904896879493180> https://twitter.com/richgel999/status/1491303414898528257

oh my god <:kekw:808717074305122316>

I think the whole spectrum from maximum compression to maximum speed is interesting and there are use cases for every trade-off

(for lossless)

there's also lossy where you have the extra dimension of loss/quality/distance — there too there are use cases for every trade-off

imo, JXL covers a good chunk of the spectrum for both lossless and lossy, in the sense that it is Pareto optimal in a good chunk of the (speed,density,quality) space

but sure there are extremes where something else will be better: if you want extreme speed (no matter the compression), something else will be better; if you want extreme lossless compression (no matter the speed), something else will be better; if you want extreme lossy compression (no matter the quality), something else will be better.

when next change in quality

probably after the 1.0 release there will be more time to go back to encoder improvements

Yep, also, I think it's better to make implementations for specific use cases in a single flexible format than to integrate many different QOI-like formats just for some specific purpose (unless it's significantly better for that)

I guess it depends on how interoperable things need to be — if it's some internal format that is used by a game or inside some hardware, it's easier tot have application specific formats, even if they only bring marginal advantages compared to standard formats.

But in many use cases, interoperability is very important and useful, which is why PNG and JPEG are still relevant even though there are formats that beat them in all technical aspects (but not in software support)

jpeg xl don't wok on pix 2.11 why

avif not

Also, even in games the existing software format has been adapted for hardware decoding instead of making a completely new one, this also helps its widespread and universality even where there is no such hardware decoder https://cbloomrants.blogspot.com/2020/09/how-oodle-kraken-and-oodle-texture.html

I didn't get if Oodle compressors source code was released with UE source code, or it is included as a binary only?

https://github.com/EpicGames/UnrealEngine/search?q=oodle

There are some headers related to Oodle, but I don't see the source code of the libraries

https://github.com/EpicGames/UnrealEngine/blob/99b6e203a15d04fc7bbbf554c421a985c1ccb8f1/Engine/Plugins/Developer/TextureFormatOodle/Source/Private/TextureFormatOodle.cpp

There are private repositories for UE subscribers, but as far as I looked, not all Oodle compressors have source code And for example some private repo clone <https://github.com/hxhb/oodle-compression>

https://github.com/EpicGames/UnrealEngine/ is actually public

You just need to tie your Epic Games account to your GitHub account to get access

https://www.unrealengine.com/en-US/ue4-on-github

And still, Oodle Lossless Image Compression does not yet have open sources

Yeah, would be nice if it were released

https://deepmind.com/blog/article/MuZeros-first-step-from-research-into-the-real-world

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

But, if it is not something like RDO-PNG and completely new non-compatible codec, how will it be better than any other modern lossy format? I think from modern formats it is possible to get very high decoding speed too, if using only fast for decoding features (at least for high bpps)

Things like DCT and color transform can be done very fast using general-purpose very-parallel hardware like GPUs or DSPs

Also, why do we need extremely fast lossy? There is a limit on how fast humans can process images...

The main use case I can think of is computer graphics, and games especially.

Texture formats is not just about being fast though - encode can be slow, and decode mostly has to be something that can be done on the fly in the gpu, i.e. you need fixed block sizes

I think people are thinking that if their image can decode 1ms faster, they'll somehow "feel" it

and even then with the current state of the reference decoder, its more then fast enough for VarDCT decodes. on all my current test image ranging from 8K down to 720P its been roughly ~130ms to 50ms

which for a webpage is fast enough at those sizes

Webpages nowadays are layers and layers of javascript frameworks, often taking several seconds before the browser even gets to make an image request

I was more thinking for when scrolling content scenarios, where the user is loading more and more content as they scroll. then it would matter if the image takes a second or 100ms to load.

but most users excuse the 1-2 second delay for scrolling.

just turn off animations

now browser feels super snappy

???

Without animations, everything is janky

https://twitter.com/jonsneyers/status/1492558805921636354?s=20&t=7lHHpdu2s7GF1GpT_oteb-cq1yc-ohFjuR8-wvpEOXw

I'm basically saying that 8-bit YCbCr is a racist colorspace and we should all use XYB

I think this features also work for non-photo content? > In JPEG XL, we finally got rid of the old YCbCr colorspace, and instead a new colorspace, XYB, is used, which is more accurately based on how the human system actually works. As a result, it's less likely to produce compression artifacts, also in dark tones. (10/14)

I think non-photos usually have much more limited and artificial colors

XYB is also suitable for non-photo, but perhaps less so than for photo. A lot of non-photo material does get created in RGB, so there are certainly cases where it's a better idea (for compression) to stay in RGB or something close to RGB (like YCoCg).

Probably can implement lossy varDCT YCoCg for non-photo content?

I think (var)DCT is only really suitable for photo and "photo-like" non-photo, like realistic paintings or renders, fps games, drawings with pencil, charcoal, chalk etc. For "really non-photographic" non-photo, like screenshots with mostly text and UI elements, logos, charts, and digital illustrations with hard edges, I think DCT is not the most effective approach. Lossless compression techniques (with lossy preprocessing, e.g. (delta)-palettization) will work better for that imo.

We already do that for patches of text (it's encoded losslessly after doing color quantization in XYB, and subtracted from the DCT image so if the color quantization introduced some error, there's still a chance for the DCT part to fix it)

What AVIF encoder did you use for those comparisons?

Because the difference can be kind of drastic(my own encode vs yours): https://slow.pics/c/pg6F7aE0

Now, it still fails where I expect it fails of course.

So I guess delta palette will implement on next improvement for "really non-photographic" non-photo? and have heuristic to switch delta palette and varDCT? (like opus have SILK and CELT)

This one is Aurora, since I just used Cloudinary to convert to avif

Libaom and SVT will most likely do the same thing though

I'll probably just start by doing simple quantization like for text. The tricky thing is to find a way to subtract without introducing border artifacts. With text that's easy because we only detect text on solid background, so we know what the "DC" of the patch has to be

Wow, I didn't think Aurora would be worse than aomenc in this scenario. I don't know if my settings are just better, but the difference is actually kind of insane.

Well we don't have latest version of Aurora in production, and we do use a fast encode setting

Oh really? I see.

That might be why then.

It'd be lovely if I could have access to it, even if for just a month 😛

Anyway, you make a great point JB.

YCbCr has run its course.

I understand, Thank you for your reply, I really look forward can use jxl for non-photo content 🙂

https://twitter.com/jonsneyers/status/1492558856756637696 in this one, i thought the right one was based on a different photo at first because of all the fuzziness

Well you can use Cloudinary to do encodes, e.g. fetch a url like res.cloudinary.com/jon/image/fetch/f_avif,q_80/https://url/to/image.png

(or just make a free account and use your own account)

<@!321486891079696385> But ask someone for a ref link before you create an accout. :D

i happened to be a cloudinary user before i ever heard about jxl

but i never used the image stuff

wait what else can you use cloudinary for?

video?

i use it to serve binary assets/fonts

https://github.com/NVIDIA/nvcomp

Something strange happened to the cloth (different more one-dimensional texture) and to the skin (upper lip/jaw oversmoothed) in AVIF

possible the cloth is spoiled by over-aeger directional prediction

and skin by just too much smoothing, or controlling smoothing with too large blocks (64x64 pixels in AVIF, 8x8 pixels in JXL)

Jon, could you show if Aurora codec can overcome those weaknesses for AVIF?

this _is_ Aurora

I'd say honestly bad default settings on the encoder's part if this is aomenc.

aomenc at the speed we need (which I guess is s8 or s9) will be even worse

https://discord.com/channels/794206087879852103/803645746661425173/943531950939971644

how does this image look with latest jyki pr

Ill wait until merge

You'd be surprised actually: https://slow.pics/c/iTuUCRIT Settings used: s9: `avifenc -j 16 -s 9 --min 0 --max 63 -a end-usage=q -a cq-level=28 -a tune=ssim -a color:enable-qm=1 -a color:deltaq-mode=4` s8: `avifenc -j 16 -s 8 --min 0 --max 63 -a end-usage=q -a cq-level=30 -a tune=ssim -a color:enable-qm=1 -a color:deltaq-mode=4`

hoiible quality fo me

but it has contast

on what vesion do you ae

https://ci.appveyor.com/project/louquillio/libavif/history

Latest.

380d91a6

to me it don't change anything

is a month i don't see changes

<@!321486891079696385>

what i'm doing wong

for %i in (C:\Users\Utente\Pictures\video\pi\a\*.jpg) do avifenc "%i" -o "%i.avif"

Settings: `for %i in (C:\Users\Utente\Pictures\video\pi\a*.jpg) do avifenc "%i" -s 8 --min 0 --max 63 -a end-usage=q -a cq-level=30 -a tune=ssim -a color:enable-qm=1 -a color:deltaq-mode=4 -o "%i.avif"`

yes but with libavif it looks the same

has same filesize

libavif hasn't changed in a month

fo filesize

why

https://ci.appveyor.com/project/louquillio/libavif/history

i always use this

i don't tust othee methods

i think this is the only method

aom is to ban

Enable qm and deltaq-mode 4, they should make that the default if it gives better results

The command line options for avifenc are really not very user friendly

Indeed. Sadly, it's obvious that JXL still curbstomps the AV1 encoders in this instance, particularly in darker high frequency areas. Even going 10-bit doesn't fix this. Even x264 and x265 struggle in this scenario: arguably more than aomenc AVIF.

Jyrki's theory is that the signaling for the filtering in avif is too coarse, forcing it to either smooth out detail or get artifacts, and basically it always has to do the former or else you'll see 64x64 macroblocks with different filtering

x265 has similar behavior where you can sometimes see macroblocks that are smoothed out that become quite obvious if they are neighboring macroblocks that didn't get smoothed

I think both have 1:64 control fields for their main filters

How could this be fixed? Would an AC energy threshold bias work to preserve more detail in areas with lower luma higher frequency patterns at the cost of DC quantization?

I wouldn't take bits away from DC in avif, it's already banding a bit too much as it is imo

my personal guess for banding in AVIF is that it's more due to too small blocks than to low DC precision

AFAIK there's no attempt to reduce banding at all in the libaom encoder, and in some sense one could say it's even encouraged

How are too small blocks a problem? Isn't it usually too large blocks that are the issue?

small blocks with 0 AC are great to get lots of banding 😄

I see. I'll take that into considerations when making my modifications.

with commit of veluca i see shapenss

at d 0.3 s seven

hthough s 8 d 0.6 theae ae evident atifacts

s nine d 0,6

on pitbull ten cuidado thumbnail though it impoved

i'll move on benchmaks

Someone make a gofundme to buy fab a keyboard with a functioning r key.

🤯 and I always thought he is illiterate

<:YEP:808828808127971399> i do it

this is just one of the reasons why I was disappointed in the codec in the first month when the first decoders appeared, I started coding - and encoder print to me, the speed was 0.00032 frames per second

this means that of the new codecs for "Normal power" people, only "EVC"(not done) remains, which is a competitor for HEVC because it is not more Compressed than AV1 or VVC, but it should be better than VP9 and HEVC at the same speeds and THE free

https://cdn.discordapp.com/attachments/816072365698973726/945773550923567174/unknown.png

Yay!

Now, I just want JXL support in ffmpeg 🙏

Or rather, libavcodec.

It would allow for much easier integration of JXL in popular programs, especially on portable Android/iOS devices.

Isn't there a patch for that already in the pipeline?

Yes 🙂 Mainly worked on by Bombzen.

I'm patiently excited of when it'll get merged 🙂

If we can get the fast lossless encoder integrated in libjxl, it would also make an interesting format for lossless video

Are there any studies that test lossless WebP performance vs PNG?

I have someone who doubts the general proficiency of lossless WebP vs PNG.

There's one on Google's webp page

For 8-bit, lossless webp basically consistently beats png

People use "PNG" to mean "has alpha channel", like they use "GIF" for "short animation"

A <:JXL:805850130203934781> file is both a PNG and a GIF. 😎

Gif

~~With normie logics <:KekDog:884736660376535040>~~

Has transparency: PNG Has no transparency: JPEG Animated without audio: GIF Animated with audio: video

~~video~~ MP4

(nah I don’t know)

https://github.com/OmarShehata/jpeg-sandbox

While yes, webp and jxl are *usually* better then png, there are weird cases where png (using ect) can outperform cwebp `z9` and cjxl `e9`. I've personally posted images where the only thing that beat png (ect) was cjxl `e9` and a few other high effort custom arguments. It seems stacked anime images preform particularly poor with cwebp and cjxl. I'd image jxl patches would help significantly but it does not seem to work? (Needs citation)

Patches work but the current encoder heuristics are limited to detecting repeated patterns in the neighborhood of 4x4 areas of single-color background.

JXL vs WebP2 triangle preview ?

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

someone to compile a new version WEBP2 with mk_preview and without AVX instructions for windows<:Cheems:890866831047417898>

I've seen the Nvidia screenshot overlay use it for HDR screenshots

xbox game bar on windows also produces jxr for hdr gameplay

JXR?

like Jpeg XR, the thing nobody uses?

<:kek:857018203640561677>

HDR. AFAIK that's all it's used for

HDR screenshots on Windows.

Encoder bug in zlib found: https://twitter.com/taviso/status/1508438583484452866?t=LbkvbhdDvMHmFS6KOOA7YA&s=19

Imagine how much stuff is out there that uses zlib encode

It's probably doable to make an image that will hit that bug when encoded with libpng

So opening such an image and saving it again as png in some editor that is using libpng for that could possibly be an attack vector

you do seem to need a non-default configuration, so there's that

it requires very low memLevel so I'm not as worried atm, but holy cow it is crazy to find such a bug

epic

patent-encumbered <:PauseChamp:755852977574510632>

ugh i'm still annoyed there's not a separate mime for animated avif

If you adopt Mozilla view on it there is no point in `.avifs` <:doge_kekw:852675429851987972>

i mean considering firefox has already had a bug on a major site because of this...

idc about the extension just a separate mime type so firefox can send a correct `Accept` header

I just used `.avifs` to denote animated, ik extensions don't matter

You don't need a separate media type, a media type can have qualifiers with more detail about what exactly is supported

All browsers lie in their Accept headers, it's kind of annoying

Iirc they all say they can deal with image/*

is there any standard way to do that for animated avifs?

Not that I know

It's kind of annoying that you need both User Agent and Accept header to know what you can send. But at least if you do it server-side, it can still be done. If you have dumb hosting and need to rely on the picture tag, I dunno what happens if you have an animated avif with a gif fallback. Will firefox pick the avif and then show a broken image, or will it fall back to the gif when the avif decode fails?

https://www.reddit.com/r/place/?cx=9&cy=711&px=28

I added a green pixel for av1

Can we put jxl somewhere? 😛

Added some more pixels for av1, it's still a mess though

Can we change .org to .jxl?

I guess it takes a coordinated effort to change anything there

``` X X X X X X X XX X X XX ```

I guess that's the smallest jxl