JPEG XL

Thanks for the tip

For this specific screenshot WebP actually had the best compression, but I will get a larger testing set by taking screenshots from multiple games

yeah, I have ~500 screenshots from over 100 different games, and in general JXL beats WebP

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

May take a while

lmao

This indeed seems like a good idea [BigBrain](https://cdn.discordapp.com/emojis/615775892177944627.webp?size=128&quality=lossless&name=BigBrain)

libjxl d0e1 runs at 500~600 MP/s so it would be like 40 mins

I feel like this is stretching the definition of "screenshot"

is it re-rendering the scene at an arbitrary resolution or what is this doing?

`The Giant screenshot, on the other hand, saves an image of the whole map at the closest zoom (excluding currently open windows); it does not matter where the user view camera is or what the magnification is. If the map is very large it will take a long time to save the image, and produce a large file. ` - https://wiki.openttd.org/en/Manual/Screenshot

I wonder how fast hydrium would encode it

decoding may be a bigger problem than encoding, because currently it's slower than e1, at least if not using cropped decoding

I am not even able to encode it, avifenc, cwebp and cjxl fail. I'll try using streaming input for cjxl

For some context, this is the minimap view of the game. Every pixel signifies 1 tile in the game, and each tile has either terrain or a building, with vehicles using sprites rendered on top. The base game is 8 bit, and will actually output 8 bit PNGs, but mods are commonly used so the game fallbacks to 32 bit. There are multiple zoom levels, ranging from +4x in and -8x out, although I'm not sure if default is exactly 1:1 with the tiles and sprite textures https://shared.akamai.steamstatic.com/store_item_assets/steam/apps/1536610/ss_8994cb799dfad2e4ba93b9f29943ceb6aeaacaf3.1920x1080.jpg?t=1701554571

Now let's see lol

because avif and webp are quite limited in image size

Can’t AVIF tile indefinitely?

There's a more complete thread of my OpenTTD compressing here https://discord.com/channels/794206087879852103/803645746661425173/1215462142963355728

yeah, av1 is limited to 4096x2304 per tile, but it's like basically separate images as I recall, glued together at the container level

While cwebp and avifenc failed to encode at all, the JXL encoded in only 32 seconds at e8 ``` WebP: Saving file 'OpenTTD_giant.webp' Error! Cannot encode picture as WebP Error code: 5 (BAD_DIMENSION: Bad picture dimension. Maximum width and height allowed is 16383 pixels.) Command exited with non-zero status 255 0:02.41 seconds AVIF: Too big PNG dimensions (32641 x 16471 > 268435456 px): OpenTTD.png Cannot read input file: OpenTTD.png Command exited with non-zero status 1 0:00.00 seconds JXL: JPEG XL encoder v0.10.3 4a3b22d2 [AVX2,SSE4,SSE2] Encoding [Modular, lossless, effort: 8] Compressed to 88550.3 kB (1.318 bpp). 32641 x 16471, 17.982 MP/s [17.98, 17.98], , 1 reps, 32 threads. 0:32.43 seconds ```

The decompressed save file for that game is 420 MB alone by the way, thankfully only a 34 MB download from the server thanks to XZ compression (Apparently?)

Try XZ compressing the ppm from the png

I don't have the screenshots anymore, they were 250 MB or something and I never took the 1 M width one so deleted them months ago

Let me upload the smaller 110MB screenshot, one second

https://files.catbox.moe/ci700d.png

Here it is

Annoyingly I also don't have the test results from back then either... Guess it's before I just dumped my CMD output into a txt file before turning my computer off :P

Here's a 'screenshot' my friend took of their last game, the site downloads the original PNG but displays jpegs for the zooming https://www.easyzoom.com/imageaccess/1eaf033ff25a41609b06f3103a307458?show-annotations=false

Ah yeas my favourite site {{meta.title}}

Biggest issue is the isometric view meaning 60% of the image buffer is just waste...

There are various profiles. You can make an AVIF that does not conform to any profile, and then the limit is 65536x65536 (which is the limit imposed by AV1 header syntax). If you want to conform to the AVIF Baseline profile, the limit is 8192x4352 and no more than 8912896 pixels (so enough for 4K). If you want to conform to the AVIF Advanced profile, the limit is 16384x8704 and no more than 35651584 pixels (so enough for 8K). Then presumably all of these limits can be circumvented by using MIAF grid derivation, though I'm not sure what the constraints are on that.

So you can’t tile past 64k?

I'm not sure, the MIAF spec is behind the ISO paywall so I cannot easily check 🙂

I tried using the --grid parameter with avifenc, but the error message was always the same `Too big PNG dimensions (32641 x 16471 > 268435456 px): OpenTTD.png`

65536 x 4096

it's funny how AVIF proponents are making fun of the JPEG XL spec being behind the ISO paywall, but actually the AVIF spec is normatively referencing the MIAF spec which is normatively referencing the HEIF spec and both MIAF and HEIF are also ISO standards and behind a paywall

Was about to say

Isn’t the whole point of AVIF to be fully open for everyone?

> Too big PNG dimensions (32641 x 16471 > 268435456 px): OpenTTD.png This is likely caused by a default limit in libpng, you can remove that limit but it requires either rebuilding your libpng with some other constants for that limit, or rebuilding avifenc so its png decoding code is telling libpng to remove the dimension limits

The most ridicolous thing about this is that the do not know even what royality free and libre mean. So they think a paywalled spec means the entire software is "NOT FREE"

I would maybe do this, if I genuinely thought that AVIF stood a chance against even the PNG.

that's at the stream level, not the container level

it's supposed to be only freely licensed patents used in it

anyway AVIF's strength is lossy, there's really no point in testing it for anything else

some group of tiles at the bitstream level, the rest is at the container level for avif, but I don't remember the maximum size, probably something up to 16k

Ok, last post about OpenTTD

``` 364M OpenTTD_giant_e8.jxl 477M OpenTTD_giant.png 546M OpenTTD_giant_e7.jxl 6,1G OpenTTD_giant.ppm ```

Encode for e8 was 2 minutes, e7 was 1 minute

🤔 I'm not sure about that, as IVF existed prior to tiles (introduced in VP9), though I suppose they could have extended the IVF spec... (or had it in the spec before any codec actually made use of it)

IVF spec is devilishly hard to find, if it even exists...

ah, yeah, because there are different profiles, so I don't really remember the exact limits <:Thonk:805904896879493180>

AVIF and JXL are pretty much exactly in the same situation regarding openness: - both are presumably royalty-free - both have good FOSS implementations available, under a permissive license (both BSD-3clause) - both have a specification that is publicly available, though there is a paywall involved for at least part of the spec - both have a specification that is not controlled by a single actor (e.g. a single company): any spec changes require a broader consensus There are some minor differences: - royalty-free: for JXL there are no challenges yet, i.e. ~~trolls~~ companies claiming you should pay them to use JXL. For AV1 there's Sisvel. - the AVIF spec itself is available without paywall, though you do also need to get access to the MIAF and HEIF specs which are paywalled - JXL is owned by the JPEG committee in which anyone can participate after becoming an accredited ISO member (which does involve paying a membership fee; the amount varies by country and situation, e.g. in some countries it is free for academics and a few hundred dollars for others, in other countries it can cost thousands of dollars), while AVIF is owned by the AOM in which it is somewhat harder to participate, there is a substantial financial cost to becoming an AOM member.

Optimized PNG?

just wait until JXL catches on and Sisvel shows up

they will attempt the same with JXL as they have with AVIF/AV1

Let me try

Curious if it goes down to 8 bit like mine did

oxipng just crashes at my default settings lol, let me adjust

Maybe ECT, it's efficent who would've guessed

yeah trolls will troll. I'm hoping we will be less affected though — video is much more of a patent minefield than still images

oxipng always crashes when it reaches +33GB RAM usage

Ok I was wrong, the crash was due to something different, oxipng is at 48GB RAM currently

one if my png images can no be converted using `cjxl v0.11.0 f28befa [AVX2,SSE2]` "getting pixel data failed" but the older version `cjxl v0.10.2 e148959 [AVX2,SSE4,SSE2]` can do it

Is it possible to send this PNG file in a zip?

Zipso discord doesn’t mess with it

Nooooooooooooo, it crashed after running for over an hour 💀

It's generally been 2x more memory efficent if you want to give it a shot

https://github.com/fhanau/Efficient-Compression-Tool

Sure, I'll have a look after trying oxipng at "-o 1" lmao

`--zc 1`

I'll add it, why not

I can safely say that JXL is better (what a surprise!), because encoding doesn't take an hour at e8

https://media.tenor.com/8CPvdgIHcZ4AAAAM/rookie-numbers.gif

Maybe if I had 128GB RAM<:kekw:808717074305122316>

what aare you trying to do?

`oxipng -Z -o max -P OpenTTD_giant.png` lol

The image is 476MiB

Well, you do need to make a 6 GB intermediary file first

Streaming the input will surely improve in the next versions making this unncessary

Trust

I *was* trying to think of how streamed PNG decoding works last night. I guess just read a fixed amount of bytes, work on that, decompress the next segment and then just re-join any split data between them since the max is 32K deflate blocks

Also the intermediary can luckily be directly streamed to cjxl using `magick`

I probably could with ffmpeg, but then I'm storing another 6 GB in memory too

```JPEG XL encoder v0.11.0 4df1e9ec [AVX2,SSE4,SSE2] lib/extras/dec/apng.cc:895: JXL_FAILURE: Exuberant input after IEND chunk lib/extras/dec/decode.cc:151: JXL_FAILURE: Codecs failed to decode Getting pixel data failed.``` The file has a bunch of data appended to the end. So I guess you have to decide whether that's important and strip it if not.

yeah sure they are not important but i gues it would be better if cjxl can handle that

and the older version that i copied from the xl converter was able to read it

idk if it's better to silently drop data or signal to the user by default

Could use tweakpng to try and see what it is

I would definitely like to know

tweakpng gives this warning

i gues if it's formated incorrectly dropping the data seems to be the correct default option

It's not necessarily incorrect though, some app probably put it there quite intentionally. In this case it seems like more image data since there's a second IEND chunk.

but it sounds like storing extra data this way is unusual and no other programm besides the one that put it there would know what it means 🤔 so the only options for cjxl is dropping this data or refuse to convert it at all right?

`oxipng --zc 12 -o 2 OpenTTD_giant.png --out OpenTTD_giant_oxipng.png` led to ``` 395M OpenTTD_giant_oxipng.png 477M OpenTTD_giant.png ```

8 bit?

Yes, but the source PNG was 8 bit as well

Right, works better than mine then

```pngcheck -vvs original.png Scanning: original.png File: original-1 chunk IHDR at offset 0x0000c, length 13 300 x 300 image, 32-bit RGB+alpha, non-interlaced chunk pHYs at offset 0x00025, length 9: 2835x2835 pixels/meter (72 dpi) chunk IDAT at offset 0x0003a, length 127682 zlib: deflated, 32K window, default compression row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth): 1 4 4 4 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 4 1 1 1 1 4 1 4 1 1 3 3 3 1 2 2 4 4 4 4 4 2 4 2 4 2 4 4 2 3 2 2 2 2 2 4 4 4 4 2 2 2 2 2 2 4 4 2 2 2 2 2 2 2 2 2 2 2 2 4 4 4 4 4 4 3 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 2 4 4 4 2 4 2 2 4 4 4 4 4 4 4 4 4 4 4 4 4 3 3 4 3 3 4 4 4 2 2 4 4 3 3 4 4 4 2 2 4 4 4 4 4 4 4 4 4 4 4 2 4 3 4 3 3 3 4 3 3 3 4 3 3 3 3 2 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 2 4 4 2 3 3 3 2 3 3 3 3 2 2 2 2 4 2 4 2 2 2 2 3 4 4 3 2 2 2 2 2 2 2 2 2 2 3 3 4 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 4 4 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 4 4 4 (300 out of 300) chunk IEND at offset 0x1f308, length 0 invalid chunk name "↨☻" (17 02 40 08)``` ```pngcheck -vvs original-1.png Scanning: original-1.png File: original-1-1 chunk IHDR at offset 0x0000c, length 13 300 x 300 image, 32-bit RGB+alpha, non-interlaced chunk pHYs at offset 0x00025, length 9: 2835x2835 pixels/meter (72 dpi) chunk IDAT at offset 0x0003a, length 31682 zlib: compression header fails checksum row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth): zlib: inflate error = -3 (data error)```

So it's a second PNG with invalid data

No wait... pngcheck was being weird, it's just creating random files with no data in them

so what are you thoughts about the correct default behavior of cjxl when dealing with images like this?

safest is to refuse to encode and let the user decide what to do. but I could also accept make efforts to encode and emit a warning when dropping data

most users will probably use software like xl converter and will never see any of these console warnings so the default choice is what they get

I am currently encoding a small dataset of 560 PNG screenshots from various games to JXL and AVIF to open a feature request for Valve's gamescope to add JXL support - 560 1920x1080 screenshots, 1,4G Is 560 images large enough or should I add more?

It sounds fine

Ideally we could throw some 4K ones in too, maybe round it up to 2 GB. Issue would be finding them :P Although that could be a separate comparison for later

I offer `Doggo.png`, a screenshot which has served me well over years of compression testing

I was thinking of creating 4K screenshots by using gamescope, since it can kinda work like super resolution. I will probably do that later, but it will take a while to go through a large variety of games, as well as having to decode the resulting AVIF to PNG after the fact.

Thanks

Yeah, especially having to encode to AVIF in 4K :P

Luckily gamescope is quite fast at encoding AVIF

gamescope is encoding AVIF at AVIF_SPEED_FASTEST, but without tiling: ``` #define AVIF_SPEED_FASTEST 10 . . . // * Speed range: [AVIF_SPEED_SLOWEST - AVIF_SPEED_FASTEST]. Slower should make for a better quality // image in less bytes. AVIF_SPEED_DEFAULT means "Leave the AV1 codec to its default speed settings"./ // If avifEncoder uses rav1e, the speed value is directly passed through (0-10). If libaom is used, // a combination of settings are tweaked to simulate this speed range. ```

To continue the encoding test of 560 PNG 1920x1080 screenshots To level the playing field I encoded JXL at e1, but also higher effort setting to compare better: ``` AVIF s10: - 0:09.23 seconds - 1,3GB JXL e1: - 0:02.39 seconds - 1,1GB JXL e2 - 0:14.30 seconds - 1012M ``` I repeated each encode 3 times and took the average. Encoded with v0.11.0 4df1e9e and avifenc 1.1.1

JXL is not only much faster but also still smaller

I mentioned it above, but the original PNGs were 1,4G

Sounds very comprehensive (as long as content is reasonably representative of general use).

It should be, these screenshots are from a variety of games, 62 in fact. I aimed at using 10 screenshots from each directory, but ended up at 560 because some directories had less than 10 screenshots

I also made sure to not only include gameplay screenshots but also menues etc.

Though the latter of course only make up a small part of the set

Very nice.

Thanks

I have a decent amount of native 4k screenshots if useful.

I'll gladly take them if you are able to share them

And I'll see if I can include some HDR screenshots, maybe from the HDR discord that was linked here a few days ago

I will continue posting here since this pertains to the gathering of images: https://files.catbox.moe/4viy1s.zip Have a zip containing an HDR AVIF created by gamescope, the decoded PNG using avidec and a JXL encoded from it. mpv is badly mangling the AVIF's colours for me for some reason, the PNG and JXL look fine.

For those interested in testing HDR without having an HDR display: you can run gamescope with `--hdr-enabled` and `--hdr-debug-force-output` and it will output HDR. It will of course look wrong on an SDR display

also avif needs validation for true lossless because not all apps do it properly and only libaom has lossless support

I made a typo here, the original PNGs are 1.2GiB, AVIF is therefore in fact 8% LARGER instead of slightly smaller

Some of the images were inflated by a factor of 8 or more

<https://mega.nz/file/7ccE2DIZ#tNBo5nxAqoAfJHm8oGIF8XvI89mSulaFdEEYEsX3OzQ>

many thanks

I can produce arbitrarily many more, from a very wide variety of games if you feel there's something lacking. Those were just legit one's I'd taken since getting the monitor.

Sure, I'll be happy to have another source for these screenshots, because taking 4k screenshots on a 1080p monitor is pretty tedious

Same as last time I am aiming for around 10 image per game, where each screenshot varies sufficiently

question is Steam still encoding "*lossless*" (not actually lossless) AVIF screenshots?

last I checked it was doing that

Non-gamescope Steam is still using PNGs while gamescope is using lossless AVIF

last I checked the AVIF outputs it was giving wheren't actually lossless

like because of the whole RGB YUV thing

Because of YUV444 you mean?

yea

Wait a sec, I saw something in the AVIF encoding funtion of gamescope about that

don't know exactly how you are submitting a request to Valve for JXL and such but maybe you should mention their AVIFs aren't actually lossless if you get the chance

``` // We are not actually using YUV, but storing raw GBR (yes not RGB) data // This does not compress as well, but is always lossless! ``` From src/steamcompmgr.cpp

Though I haven't verified this

Here's a gamescope AVIF, if you want to verify

oh huh I guess it is fully lossless it seems. I was checking in the wrong way the first time around

How are you checking? For me ImageMagick's identify and avifdec seem to suggest YUV444

I originally was using exiftool but I got suspicious it wasn't actually telling me what it was so then I put it through ffprobe (from ffmpeg) and it says it's gbrp10le

Ah alright

AVIF lossless is just pain <:SadCat:805389277247701002>

yeah

It is still sometimes smaller than PNG, but sometimes it is also much larger

they are trying to make it better in backwards incompatible ways that still don't even get close to JXL: https://github.com/AOMediaCodec/libavif/issues/2077

wouldn't be surprised if one day they decide to start putting AV2 streams in AVIFs

It'll be some more years until AV2 is ready, no?

Or am I out of the loop?

i'm also out of the loop but I meant as in the future when AV2 is actually done/ready

When that happens it may *hopefully* be better than AV1

AVIF to me seems like a live service format where they just decide to randomly add backwards incompatible stuff. imagine if the same was done with PNG and people started getting PNGs on their computers that other programs can't open

I already posted an HDR AVIF earlier that I couldn't get to display correctly anywhere, except in Chrome. Displaying HDR content is not even that well implemented in windows image viewers, but it is still worse on linux. But that is the problem with HDR content on any system, including mobile OSes, at this time. Except maybe macOS.

I played with AVM a few months (research 7.0 branch), and quality was noticeable better than AV1

but right now, the encoder is so slow that it takes like a minute to encode a single keyframe, I so just limited my testing to just images

How does it compare to JXL?

I limited my testing to the low-mid fidelity lossy range (as I was interested in exercising the new low-bitrate coding tools), so I'm not sure how it does at the higher-fidelity range

but my understanding is that there are improvements all across the quality range to various degrees

but the current slowness is intractable heh

if I were to spitball a number... AVM r7.0 was 15-20% better in intra-only than aomenc at cpu-used 0 intra-only

Does this encoder support lossless?

it does, by virtue of inheriting the AV1 codebase

but I don't think there has been any meaningful work to improve lossless though

Ahhh alright

I see, I will work on round two then.

I already have around 300 screenshots at this time, but I'll take all you can offer

Btw, looks like 0.11 is slower and usually denser than 0.10.

Good to know

dense being better compression?

better mean bpp

What games have you already sufficiently covered?

This is lossless? Are the same gains for lossy as well?

oh, yeah, lossless. lossy would require actually looking at the images ...

I made a few comparisons earlier this year: https://github.com/libjxl/libjxl/issues/3530#issuecomment-2132164263

It's definitely a noticeable improvement for screenshots/artwork

For photographic content it's harder to see a difference, it's one of those things where preferences for artifacts and detail retention play a big role in what one would consider "image quality"

Are there any image codec comparisons between aom and avm? https://gitlab.com/AOMediaCodec/avm

I heard someone say that avm has big improvements over avif despite not being optimized for still images.

fab talks about it a lot

Fab mostly talks about things existing only in his head, so I would not take it seriously

At this time I have 380 images from maybe 10 games on my side, nonidea from how many games the files you sent me previously are from. Unless you have +10000 images I will take all you can send me. I aim at a very large datset to be representative of different types of graphical styles/games this time.

Games that are covered ar this time - Satisfactory - Factorio - Star Wars: Outlaws - One of the Yakuza games - CS:GO - WH40K Boltgun - Holocure - Doom Eternal

I heard it from this article: https://www.autocompressor.net/blog/progressive-avif But I cannot find ANY comparisons between avm and aom.

So I wonder where anyone would even get that impression or how you could even test it out since I don't think avm is integrated into libheif or ffmpeg or anything

Maybe someone on the AV1 discord conpared then?

If you wanted to give AVIF a nice punch, you could throw in some OpenTTD screenshots (Although maybe not above 8K)

While true, I try to be objective in my selection

And besides, JXL beats AVIF even without cherry picking ;)

speaking of openttd, I did download it on my phone to try it because of the chatting of it, doesn't seem very usable on phone lol

That's probably like trying to play a desktop game directly on a phone display in terms of UI

It does work... Surprisingly well, but the UI is still very much in the 90s so trying to use it on a phone is... A talent

it's also very... wide

AVM is in constant development, so any comparisons between it and AOM are bound to become obsolete

we'll most likely have to wait until like 2030 for mainstream AV2 to be a thing 😄

At this time I have 380 images from

Accidentally sent that one with CPU time. Here's the more practical real time plot.

is bottom left best?

bottom left is best bpp, worst speed

so top left is best?

the pareto front is represented by points for which there are no points both further left and further up

it is not so interesting here, the general conclusion is 0.11 is slower and denser

mixed results on ui/text. 0.11 is denser at lowest efforts, less dense at mid-higher efforts

Anyone recommend some good images for lossy codec stress testing?

Images that are a problem for avif or jxl

or any lossy codec.

So far I really like this image because there's so much stuff that lossy codecs hate in it: https://storage.googleapis.com/avif-comparison/images/subset1/sample_images/2011-03-05_03-13_Madeira_159_Funchal__Mercado_dos_Lavradores.png

yes that's a nice one

`avifenc -j all --autotiling -q 50 -s 4 mercado.png mercado.avif` `cjxl.exe -q 75 mercado.png mercado.jxl`

The <:JXL:805850130203934781> is superior in almost every way except one

the colors are notably less vibrant. Everything else is noticeably more detailed and closer to the original, except for color.

generally problem images for avif are these: - close-ups of human faces — avif will smudge any subtle skin texture - nature photography (e.g. landscape with lots of trees, bushes etc) — avif will require lots of bits for all of the entropy in such images - clouds — it smoothes them into plastic balloons - anything with subtle, low-contrast textures, e.g. concrete walls, marble statues, etc — again, will be smoothed into oblivion typical problem images for jxl are these: (or rather, images where avif can look better than jxl at low-medium quality) - anything with high-contrast edges — jxl will have ringing artifacts while avif can avoid those better even at low quality - anything where "smoothing things into oblivion" is not considered a problem, like images of shiny cars or colorful balloons, or noisy skies where avif's "denoising" can be preferable to jxl's attempts at preserving the noise.

`aom [enc]:3.6.1` `cjxl v0.11.0 4df1e9e [AVX2,SSE2]`

But smoothing the noise is never preferable if the goal is fidelity.

But yeah, images that are already smooth to begin with are definitely avif's strong suit.

If I was viewing or showing a flicker test of a noisy sky image, and one encoder shows all the noise smoothed out, that would look pretty embarrassing for that encoder.

Assuming you have the original to compare against.

If anyone has any specific images, like a detailed facial close up, or anime, or a sky, or marble and concrete, etc... I would like to experiment with them and maybe make some nice comparisons showing jxl's progress

You might want to check older versions of libjxl too. I know that was a regression but can't recall which release

I think I am one of the first to point out the loss of color in the first place :) And it's been a problem for a long time it looks like.

In this mercado image, it's particularly important for the thin red beams in the bottom right of the image.

Can you fix point 2 by denoising before JXL ?

Yeah I remember you mentioning this a few months ago

denoising before encoding will probably reduce the bitrate a lot by making the image easier to encode (removing entropy from the image)

Since AVIF is doing it anyway, could JXL do that as a preprocessing step for really high distances

Only if they name it "avif mode"

Maybe chroma is being rounded down instead of rounded to nearest?

As an optional flag ofc

that is kinda what it looks like... It just looks really desaturated.

but theoretically if this was implemented could it help JXL be more competitive with AV1 at low quality ?

300 ms to open avif vs 16 ms for jxl 🤦‍♂️

Personally I don't like this idea. A codec should reliably transmit a signal faithful to the original signal. I think, if there is a problem with the transmission, and the transmission does not contain enough information to reconstruct a clear and accurate representation of the original signal, it would be nice if that were more obvious and somehow conveyed to the viewer in a way that minimally obscures or distracts from the information that's present. And I think blue noise is the perfect way to convey that, as noise is already universally interpreted by all as a sign of a weak signal, and blue noise in particular is easy to see through, minimally obscuring what's underneath. That's why it's used so well in dithering.

there is a horizontal line going through the middle of the image, where pixels are shifted somehow...

introduced by the camera maybe?

most visible in the fruits

I wonder what's the origin of that. Looks like the picture is pieced together without being perfectly aligned

the original source of this image is https://upload.wikimedia.org/wikipedia/commons/2/2f/2011-03-05_03-13_Madeira_159_Funchal%2C_Mercado_dos_Lavradores.jpg

WTF

there is something very weird going on

Not only does it look desaturated, it looks like the chroma channels are just heavily distorted in general, almost like they're being stored at a lower resolution, and with more severe ringing artifacts and quantization noise.

But when it comes to the creases on clothes, the texture on walls, etc, it's way better than the avif.

that line you see <@401816384109150209> , is it going from the cauliflower to the oranges? I don't think there's something wrong, just some details in the image happen to line up by accident, and after the downscaling it looks a bit like a seam or something

pretty good work overall especially people working primarily on lossy psycho tuning like Jyrki :)

Overall I would say it's slightly better than aom, after deducting some points for the color.

no, that one might be natural...

could you describe where this line is then? I can't seem to see it

I will come back to this...

because the actual weird thing is not the existence of that line, but something else with it... need a bit of time to investigate...

I even tested out lossy modular... incredibly, even though it's far less mature, it does just as good as vardct on this mercado image!

I feel like lossy modular might have some serious untapped potential

It has the same exact color issue too, so I think it must somehow share some code with vardct even though it's a completely different method of quantization

it definitely has. Wavelet based image compression is a pretty good idea in general and the way it's designed in jxl is very, VERY clever from what I can tell

But modular is a pretty blanket term in jxl to refer to anything that isn't vardct

lossy modular seems like a super improved version of jpeg2k

What else is there?

You can’t use RCTs alone to compres

modular has a whole bunch of different modes and knobs and switches.

"lossy modular" is synonymous with Squeeze/Haar wavelet transform

So does VarDCT though

modular also has some stuff from webp-lossless and a whole bunch of tools for lossy and lossless coding.

splines are considered part of modular mode too I think. Anything that isn't vardct.

patches and dots too maybe?

both vardct and lossy modular use XYB, maybe the balance between luma and chroma should be adjusted a bit

Keep in mind the problem is only noticeable at low bitrates. I wouldn't want to make a suggestion that only works on low bitrates but harms things on high bitrates.

with modular, maybe one can do some simple edge detection transform, put data from the transform into hidden channel, and do some prediction with the hidden channel

but maybe the hidden channel doesn't compress very well

one thing is that both are basically scaling the amount of quantization in the same way for luma and chroma, as in: the amount of quantization is different for each X,Y,B component, but the way it scales with the distance setting is the same (if I'm not mistaken)

it could be useful to apply different scaling curves to the quantization, since chroma starts out already rougher than luma so if you go to lower quality, you might run into chroma issues earlier than luma issues

Yeah, we need to make sure the chroma does quantise to a point where it’s noticeably dulling colours

there's insane untapped potential :) For extremely low bitrates, you could use some really expensive but effective techniques like spline detection and image decomposition into multiple layers for encoding different parts of an image in its most effective encoding.

Less accurate colours, sure, but we don’t want noticeable dullness

that makes sense. It's not taking into account that it's already coarse quantization to begin with and it shouldn't go below a certain extreme-o quasimodo uglisimo setting

Ok, I found out what is going on. Gwenview, eats up an entire line of pixels when displaying the image at 100% scaling. So does it when watching at 200%. At 400%, not anymore (most likely because the scaling method changes). So, most likely you could not see what I was seeing because your image viewer actually displayed the image correctly. Gwenview eats up the same line when displaying the image transcoded to JXL. But it eats up a different line when the image is transcoded to AVIF.

So, don't use Gwenview, I guess.

why does it eat a line when viewing at 100%? that doesn't make any sense

indeed it doesn't

it's supposed to not do any scaling at all and just send the pixels 1:1

right

Setting display scaling from 125% to 100% fixes the issue.

Using KDE Plasma on Wayland btw

GPU drivers may be eating the pixels then

All other applications can display everything correctoly, MPV, qimgv, ...

also very weird that with AVIF, the missing line is a different one

I assume because it decodes to YUV, not RGB?

still makes little sense

Vaguely related, but if I recall above distance 20 cjxl downsamples the image and raises the quality again to compensate

Could try delta palette, but that's only cjxl 0.6

probably some tiling + off-by-one

Continuing from https://discord.com/channels/794206087879852103/804324493420920833/1286484147518570547. I have not tried e10. Tested with 0.11.0 No settings were given besides effort. ``` 226852 The_Night_Watch_-_HD_e1.jxl 226852 The_Night_Watch_-_HD_e2.jxl 207704 The_Night_Watch_-_HD_e3.jxl 207704 The_Night_Watch_-_HD_e4.jxl 207704 The_Night_Watch_-_HD_e5.jxl 207704 The_Night_Watch_-_HD_e6.jxl 207704 The_Night_Watch_-_HD_e7.jxl 204472 The_Night_Watch_-_HD_e8.jxl 204040 The_Night_Watch_-_HD_e9.jxl ``` e1 to e7 all took pretty much exactly 60 seconds to encode as well as very similar CPU and RAM usage. More interesting are the filesizes of the recompressed JXLs. e1 to e7 pretty much all behaved like the attached graph shows.

The plots for e8 and e9 also look similar, except e9 took much longer

I posted this as graphs instead of numbers to show the resource usage over time

I also tested how much respources are used to open the images. I worked around the Qt-JXL-plugin limitation by recompiling Kimageformats. I switched from gwenview to nomacs because it is faster and uses less resources. e1 to e6 also look very similar here, it gets more interesting at e7 to e9.

When comparing 0.11 to 0.10, I notice there is a difference but unfortunately I don't notice any remarkable improvement yet. Maybe the improvements are only apparent in a particular image type.

As far as lossy/psychovisual performance goes.

I don't think there are any _big_ differences between 0.10 and 0.11 in terms of encoding/quality.

I know it was being tweaked, but idk what type of images it was being tuned for.

tried this one for luls, it somehow encodes but jxlinfo got confused at the end

I was curious about how this image would fare with SVT-AV1-PSY (tune still-image, preset 3) and it does seem to do significantly better compared to aomenc at this size

the difference is most noticeable around the column's texture, PSY retains it much better despite using 8% less bitrate

Hmm...

But your AVIF is using chroma subsampling

I can tell by how dreadful the red jacket looks :D

So it's not a direct comparison to the 4:4:4 avif

IrfanView opens it as black screen, FastStone says it won't open without installing AV1 extension from MS, that is actually installed. Other avifs are opened fine by both viewers

correct, SVT only support 4:2:0 right now 😭

:(

no idea what's going on to be honest... opens on default MacOS viewer, Safari and Chrome

FF also opens it without issues

also, there are some viewers that display 4:2:0 chroma with nearest neighbor interpolation, which looks 🤮

why tf

waterfox also opens it

yeah, waterfox uses nearest neighbor too

so that's why it looked trash

:/

i thought it was just low bpp

I can tell by the pixels, and by seeing many neighbors in my time.

when zoomed in it's quite obvious blocking

This is just a native issue with avif ~~(and all video-based image codecs)~~, the spec doesn't actually require chroma upsampling, it's expected that video players/image viewers do their own chroma upsampling. It's a strange leftover from the video codec world.

Relevant issue: https://github.com/GoogleChromeLabs/squoosh/issues/1368#issuecomment-1589663546

even av1 doesn't specifiy?

it's a video codec thing. all videos don't chroma upsample, your video player does that

at least that's how I understand it

i would expect them to at least specify an upscaling mode?

does the h.26x formats specify?

webp assumes bilinear

https://fossies.org/linux/libwebp/sharpyuv/sharpyuv.h

Assumes that the image will be upsampled using a bilinear filter. If nearest neighbor is used instead, the upsampled image might look worse than with standard downsampling

`avifdec` I think does have bilinear chroma upscaling enabled by default.

but again it's not required by the spec, which is a problem

Does JXL specify?

Yes

Although is it just used for JPEG or can you enable it?

This is a typical difference between video and image

Still image codecs consider color transforms and chroma subsampling as part of the codec, basically as coding tools that need to be specified

Video codecs consider those things "application problems"

Bruh

Libjxl only used ycbcr when recompressing JPEGs, when doing lossy from pixels it only uses xyb and doesn't do subsampling

Though libjxl does use whole-image downsampling when you go down to really low qualities (d>20 iirc)

whole-image downsampling like it just cuts the resolution by 2?

It's an implicit `--resampling=2` right?

Yep

Yes

is subsampling coded per frame or per image?

Per frame

i guess you could seperate the image into more and less important parts and use patches to have some parts more and less resolution

Yes, such things are possible.

like if it's an image of a sign on a background, you can make the sign clear and make everything else downsampled

Maybe in the far future with lossy e10/11?

Wishful thinking I know but I like to dream

since there are so many coding tools, if jxl becomes fully mainstream im guessing people will make forks that are tuned for specific needs

like one for good quality at ultra low bitrates

or fast high quality but don't care about ratio as much

Considering how expressive the bitstream is, the possibilities are endless <:pancakexl:1283670260209156128>

Yes, there is a lot of room left for more advanced encoding approaches

1. Design a future-proof, very expressive image codec. 2. Implement a complete and fast decoder. 3. Implement an encoder that is good enough to show the potential. 4. Get enough adoption so people can conveniently use it in practice. ---- we are now here ----- 5. Get universal adoption so interoperability is not an issue. 6. Make better encoders that make use of more of the available coding tools. 7. Get better at niche/atypical image content (currently focus is mostly on photos) 8. Get (more) applications to support new functionality that jxl enables, like layers and the various extra channel types.

can JXL [simulate an entire computer system](<https://en.wikipedia.org/wiki/FORCEDENTRY#Exploit>) ?

I don't think so. Or at least it will have very limited resources. It's not Turing complete.

₩Ɇ ₩łⱠⱠ ₮₳₭Ɇ ØVɆⱤ ₮ⱧɆ ₩ØⱤⱠĐ Ø₣ ł₥₳₲Ɇ₴

so *that's* why it's called "long-term"

does the X stand for something in perticular?

I wasn't there when JPEG chose a name

But they had XR, XT and XS already

probably eXtended or eXtension

or maybe Elon musk works for JPEG

JPEG XL: JPEG Extended Long-term

Using a 3 layer image with blend you could make your own chroma subsampled image ;P

i guess

I stumbled across that while looking into https://github.com/libjxl/libjxl/issues/3775

As the researchers said "Amazing but horrifying" or something along those lines

One idea was JPEG XtendedLife To try and live as long as the original JPEG has

so after about 2 weeks roughly 20% of my png images are already converted to jxl with effort 11 <:Stonks:806137886726553651>

Jpeg XL is "Turing complete" within 1024 x 1024 px https://dbohdan.com/jpeg-xl

JPEG Excel?

how many images, or perhaps more importantly, pixels, do you need to convert?

because that sounds like a hell of a lot...

Effort 11 is just silly

the size of the images is variable there are many small images like 300*300 that take like 3-4 minutes to convert (with one core) and some much bigger files the folders that are converted are in total around 5GB and the ones that are not around 20GB but beside the png files they also contain jxl files that are converted with effort 9 🤷‍♂️

it's a bit messy

a small image takes 3 to 4 minutes?!

and there are also a few images that failed to convert with the newest version but overall just a few I'll deal with them when the rest is converted

effort 11

yeah, I'm not on a new enough <:JXL:805850130203934781> to have access to that yet

thats why they hide even the option to use it by default

it was added in 0.11.0?

it was there before but 0.11.0 made it much faster

usually it only lets you do 10

but with this you can use the good stuff

ahh, I see <:PepeOK:805388754545934396>

and then there is also this

yeah, e 11 is not worth it...

but i haven't gotten an executeable for that but for now e11 should be good enough

I would only bother with e 10

e 11 is just terribly slow

all i hear is weakness

all I hear is practicality

honestly I produce images faster than I can encode them in e11

so I would literally never finish encoding them if I used e11

don't question e11

yeah if i would add new png faster i would have to give up on 11

e11 ftw 💯

it is an expert option, so it's obviously good

<@384009621519597581> some experiments with patch detection on tiled images https://discord.com/channels/794206087879852103/803645746661425173/1247714711777054730 https://discord.com/channels/794206087879852103/803645746661425173/1280929625555603480

👀

love me some patches

`Trying 512341239571 combinations... Waiting until a better compression algorithm is invented... Estimated time: only 3 seconds... relative to the predicted heat death of the universe.`

<:Poggers:805392625934663710> https://github.com/WangXuan95/NBLI

<https://github.com/WangXuan95/Image-Compression-Benchmark>

Would be interesting to add multithreaded results to that...

Also: why make a new lossless format in 2024 that can only do 8-bit?

How does it work?

What algorithm)

That looks like multithreaded to me, matches my speeds on cjxl with 8 threads at least

`3840 x 2160, geomean: 92.225 MP/s [87.51, 94.23], , 10 reps, 8 threads.` `3840 x 2160, geomean: 22.040 MP/s [21.63, 22.27], , 10 reps, 0 threads.`

```All above compressor/decompressor are tested in single-threaded, See Lossless-Image-Compression-Benchmark for detail.```

Then either their CPU is 8x faster than mine, or they didn't realise cjxl runs multithreaded by default

They must assume num threads 0 means no multi threading

It does

As in single threading only correct

```wintime -- cjxl -d 0 --disable_output Test.png -e 3 --num_threads=0 --num_reps=5 JPEG XL encoder v0.11.0 0185fcd [AVX2,SSE2] Encoding [Modular, lossless, effort: 3] Compressed to 9481.4 kB (9.145 bpp). 3840 x 2160, geomean: 4.056 MP/s [4.02, 4.10], , 5 reps, 0 threads. PageFaultCount: 738871 PeakWorkingSetSize: 233.5 MiB QuotaPeakPagedPoolUsage: 32.93 KiB QuotaPeakNonPagedPoolUsage: 14.2 KiB PeakPagefileUsage: 262 MiB Creation time 2024/09/24 18:28:41.369 Exit time 2024/09/24 18:28:51.825 Wall time: 0 days, 00:00:10.455 (10.46 seconds) User time: 0 days, 00:00:00.718 (0.72 seconds) Kernel time: 0 days, 00:00:09.734 (9.73 seconds)``` ```wintime -- cjxl -d 0 --disable_output Test.png -e 3 --num_threads=8 --num_reps=5 JPEG XL encoder v0.11.0 0185fcd [AVX2,SSE2] Encoding [Modular, lossless, effort: 3] Compressed to 9481.4 kB (9.145 bpp). 3840 x 2160, geomean: 19.078 MP/s [18.65, 19.58], , 5 reps, 8 threads. PageFaultCount: 819563 PeakWorkingSetSize: 237.1 MiB QuotaPeakPagedPoolUsage: 33.18 KiB QuotaPeakNonPagedPoolUsage: 17.52 KiB PeakPagefileUsage: 279.8 MiB Creation time 2024/09/24 18:29:34.123 Exit time 2024/09/24 18:29:36.520 Wall time: 0 days, 00:00:02.396 (2.40 seconds) User time: 0 days, 00:00:03.453 (3.45 seconds) Kernel time: 0 days, 00:00:11.437 (11.44 seconds)```

0 threads means no multithreading, and 8 threads matches their results, so either something went wrong or they got a magic 5x encoding boost

maybe it's because you're comparing MB/s to MP/s

That's a 3x difference for 8-bit RGB

verypog ```JPEG XL encoder v0.14.0 890f6hdf [AVX10,AVX2,SSE4,SSE2] Encoding [Modular, lossless, effort: 14] Trying 97960325 configurations, please be patient ...```

It's a bit of a shame that for 1 bit of images like 64x64, the maximum compression configuration is achieved already on the parameters -e 5. And no further new breakthrough are taking place... It's like being stuck in a local minimum

Never even occurred to me that they'd use MB/s for image comparisons, but I suppose it makes sense. Thanks for pointing it out

There is this https://github.com/libjxl/libjxl/issues/3775#issuecomment-2317324336

> The trick here was to apply one squeeze step followed by a palette step, which has the effect of turning the 1-bit image into a 2-bit image of half the size. This image compresses better since the MA tree gets a larger effective local neighborhood for context, etc.

Could this work with 2 squeeze steps and a 4 bit image?

Nevermind squeeze only applies to one half of the image

Images which show texture (stone etc.)

Has anyone benchmarked a dataset exclusively comprised of HDR images and compared JXL to AVIF?

We recently did that in JPEG with some objective metrics. Now we're going to try some subjective experiments...

Hey guys. I was annoyed with how vipsthumbnail introduces significant halo artifacts when shrinking images intended for codec testing. I'm trying a new vipsthumbnail command for improving the quality of the output. I'll post the command line arguments in a bit.

`vipsthumbnail -a -t -i srgb -e ./sRGB_v4_ICC_preference.icc -n perceptual -r none -p vsqbs -s 1000x> -o 'tn_%s.jxl[lossless,effort=2,keep=icc]' input.img` The documentation for vipsthumbnail is pretty bad. Here's an explanation. `-a` linear light resize. disables all shrink on load mechanics so it's significantly slower `-t` auto rotate based on exif tag, probably not needed and done by default now `-i srgb` for untagged images, use srgb `-e srgb` export color profile, can also put `srgb` here or a filename. `-n perceptual` profile rendering intent `-r none` no stupid sharpening filter that causes halo `-p vsqbs` new, apparently fast and high quality resampling algorithm instead of the default bilinear method, I haven't really tested it though... `-s 1000x>` resize if more than 1000px wide `-o 'tn_%s.jxl[lossless,effort=2,keep=icc]'` output format template (lossless jxl effort 2 with `tn_` prepended to the filename hope this helps!

For list of alternatives to vsqbs try `vips --list interpolate`

vsqbs seems to be the fastest :)

here's a good illustration of the crushed shadows on d=1

Here's a really good one, if you look at the dark patch on the right side of the image.

Just look at any areas that are really dark.

Keep in mind that the source has color profile information attached (I used jxl as the source.)

Also look at the blurring behind the woman at the bottom right:

Overall, I think the encoder probably reserves too many bits for high-contrast areas where a small amount of distortion is harder to notice... and too little bits for low-contrast areas where the same amount of distortion is much easier to notice.

In order to fully appreciate the effect you need to look at dark images with lots of stuff going on in the deep dark shadows.

Most images don't have so many really dark regions with lots of subtle shadows, figure and textures happening in the darkness.

Dark materials would also probably have their textures blurred.

If only we had more dark test images :)

Maybe it's a color profile error...

source: https://wallhere.com/en/wallpaper/566971

Something REALLY weird is going on here. Look how busted THIS image is. source: https://wallhere.com/en/wallpaper/773518

It looks like the color profile is being misinterpreted.

Anyone else notice something extremely wrong in this last image?

The d1 encode is bt2020, the source image is bt709

Indeed, converting the source_wood.jxl rsults in a bt2020 JXL

Only happens with lossy encoding

Lossless retains bt709

weird

passing `--disable_perceptual_optimizations` while converting results in the output being bt709, same as the input

But the image looks worse due to this option being specified lol

what? Well that's weird. That's definitely some sorta bug that might not actually have anything to do with psycho at all

how can you tell?

what happens if you `djxl --color_space=RGB_D65_SRG_Per_SRG` repacling whatever is needed?

ah colorspace shenanigans, this is why I just encode everything in srgb to eliminate all variables when testing

I don't trust any program to handle color correctly

jokes on you, now you have one of the largest variables that exists, hard coded display/application variations

Now half the color-managed software will decode as gamma 2.2, the other as inverse sRGB OETF. So will half the displays.

https://tenor.com/view/sisyphus-rael-gif-943215023730044045

It never ends, color management is such a pain

it really is

use android + TV for 1886 [av1_chad](https://cdn.discordapp.com/emojis/862625638238257183.webp?size=48&quality=lossless&name=av1_chad)

why is displaying color such a mess?

well, it's a combo of paywalled specifications and it just being super complicated

this is why I want PQ to catch on so bad because it simplifies a LOT of things

because some transfer curves have mismatched OETF and EOTF

and because displays don't signal to the OS what they use

and because the OS does not signal to applications what the display uses

I mean, in sRGB's case the "reference display" is pretty simply defined.

the issue is the paywalled spec allowing people to push their own BS

isn't that just gamma 2.2?

yeah, but some displays use the inverse oetf

yes

The issue is, for correct reproduction, you should always encode using the inverse EOTF.

OETFs that are not the inverse EOTF are just stupid stupid stupid.

They distort the image.