JPEG XL

Huh? I thought PNG only has premultiplied?

PNG is a really badly designed format that shoots itself in the foot repeatedly

It will never be good

Although it is "good enough" most of the time

No, the spec specifically forbids premultiplied

> When I and the other creators of PNG were defining the way alpha channels are stored, we generally all agreed that the only benefit of premultiplication was faster compositing. File formats designed for long-term information storage should contain all the information, not just what shows up in the final image, and premultiplication involves irreversible information loss. So technically, if a PNG image is premultiplied, it is not a compilant PNG (though that doesn't prevent software from producing them anyway). But that's why there's no metadata to indicate premultiplication in a PNG--it's strictly not allowed.

Oh, so every viewer just does the multiplication themselves?

I thought Apple introduced premultiplied PNGs? Or am I wrong?

yes, as a private extension

some discussion here: https://github.com/w3c/png/issues/45

most just pass alpha through as is

some good viewers will do it properly

I bet they aren't going to add another way of associated alpha until they get response from Apple.

Actually, <:JXL:805850130203934781> has already been deboonked by Chrome Codec Team. PNG and WebP should be used instead of a JPEG.

debonked 🔨

:)

PNG is the next gen format of the future

No! BMP is the best format!!

PPM.br

JPEG XL is future proof by allowing storage of images in the brob box

`.farbfeld.bz2`

the [APNG patch for libpng](https://sourceforge.net/projects/libpng-apng/) which has existed and been maintained since at least 2010 (at least 15 years) has finally been merged into mainline libpng as of yesterday \🎉 https://github.com/pnggroup/libpng/pull/706

would there be any merit for jxl to be decodable to this png v3 in place of current png profile ?

like if jxl has true/gainmap hdr or any other features not previously supported by this newer png spec

AFAIK all were already implemented

Now we just have to wait for debian to update to the new version

Like seriously when Mozilla first introduced apng everyone adopted it very quickly while the PNG guys were still trying to insist on their failed and doomed MNG format

Which was already flat out rejected by everyone

It took this long for them to get the message

Probably because everyone died of old age and were replaced by different people

Those were the days, back when Mozilla actually did things and invested in world changing tech, before Michelle Baker fleeced and hollowed out the company for her own personal gain

Yeah APNG and mozjpeg are innovative

and later the foundation was struggling with buying some services and shutting them down

firefox should be funding firefox. let any other side projects run off their own funding or take an internal loan meant to be repaid from success

biggest mozilla fumbles was dreamcasting itself. web services *independant* from the firefox browser shouldve thrived even if you didnt use firefox

take deviantart and tumbler, they had the chance to acquire both at less than 30 million dollars, be profitable from year 2 with massive potential for monetization and tech pushing and they lost this chance to web grifters

same with cliqz wich they lost (sorry its 'brave search' now)

web services like a (mozilla-owned, NOT mozilla-branded) webhost, blog hosting generated massive profit even before cloud hosting padded em even higher

Yeah but they HAVE to raise their own salaries and spend over 30% of their money on paying their executives. How else are they going to stay competitive when attracting new talent? Never mind the fact that their fat asses are glued to the executive chair and no fresh blood is coming in.

They're literally just giving themselves money and hollowing out the foundation like termites

I never knew about this. Good thing they're getting paid competitive compensation for their masterful management of mozilla though

They've really earned it, by thinking inside of the box, cracking down on any ambition, and just focusing on giving themselves more money without any plan for the future.

So... Other codecs huh?

PNG = best codec of the future

No further innovation needed now that we have the ultimate format

But the working group wants further innovation like better compression rate

No, it's already perfect with its misaligned data structures and zlib compression

It's all part of the larger genius of PNG

"Better compression" may simply be with current techniques from some optimisation tools

~~I think you mean tiff~~

TBH, I think it would be better to freeze PNG as it is now, rather than adding new compression methods or other backwards-incompatible new stuff. As it is now, it is fine. Very interoperable. Adding incompatible new compression methods will just turn it into a TIFF.

It's just got defrosted

We need to add iJXL chunk

completely agreed. one of the reasons people claim JXL was rejected was that it increases a browser's attack surface; this will happen if we update old specs as well

It's just very annoying from an interoperability point of view: imagine I do an upgrade of my libpng and suddenly the PNGs I produce are no longer decodable anymore by most other people. This kind of thing makes people very angry and frustrated, understandably so.

if that happens imma be pissed im not gonna lie. I will be one of the *worst* issue reporter folk lol

At least this doesn't happen with spec 3rd

I assume it will never happen. If you introduce such breaking changes, you might as well call it a new format.

advanced network graphics ANG

PXL

technically, some of the new stuff *could* be critical for rendering like the metadata stuff, but nothing a decoder should ever get hung up on

> PNG Fourth Edition, which we are working on now, is likely to add gain maps. > > However, gain maps are extra data. So there is a trade off. > > The reason gain maps didn't make it into Third Edition is it isn't yet a formal standard. We have a bunch of the work ready to go once their standard launches.

PNG Eleventh Edition, which is currently in the planning stage, will add support for a new compression mode named Modular mode. However, Modular mode is not forwards compatible with existing decoders. So there is a trade off. The reason Modular mode didn't make it into Third Edition is due to it already being a standard. That standard is called JPEG XL. We have a bunch of the work ready to go once their standard becomes mainstream. What?

> Q: Does it have any advantage over Lossless encoding in JPEG XL? > A: > Yes, lots. > > The big one is adoption. I love JPEG XL and hope it becomes more widely adopted. It is very scary to add a format to a browser because you can never remove it. Photoshop and MSPaint no longer support ICO files, but browsers do. So it makes sense for browsers to add support last, after it is clearly universal. I think JPEG XL is well on their way using this approach. But they aren't there yet and PNG is. > > There is also longevity and staying power. I can grab an ancient version of Photoshop off eBay and it'll support PNG. This also benefits archivists. > > As a quick side note on that: I want people to think about their storage and bandwidth. Have they ever hit storage/bandwidth limits? If so, were PNGs the cause? Was their site slow to load because of PNGs? I think we battle on file size as an old habit from the '90s image compression wars. Back then, we wanted pixels on the screen quickly. The slow image loads were noticeable on dial-up. So file size was actually important then. But today?? We're being penny-wise and pound-foolish.

> Our first goal is to see what we can get for "free" right now. Most of the time, people save a PNG which is pretty far from optimally compressed. Then they compare that to another format which is closer to optimal and draw a poor comparison. > > You can see this with PNG optimizers like OptiPNG and pngcrush. > > So step 1 is to improve libpng. This requires no spec change. > > Step 2 is to enable parallel encoding and decoding. We expect this to increase the file size, but aren't sure how much. It might be surprisingly small (a few hundred bytes?). It will be optional. > > Step 3 is the major changes like zstd. This would prevent a new PNG from being viewable in old software, so there is a considerably higher bar for adoption. If we find step 1 got us within 1% of zstd, it might not be worth such a major change. > > I don't yet know what results we'll find or if all the work will be done in time. So please don't take this as promises or something to expect. I'm just being open and honest about our intentions and goals.

Some interesting quotes from the chair

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

It would be more fun if he joins this server

I will say that at the very least the PNG spec has always had dedicated space for new incompatible compression schemes and delta filters marked as "reserved for future use" so to a certain extent adding new compression methods and such wouldn't *entirely* be wrong exactly

He already said W3C won't approve if it breaks compatibility

it doesnt matter if a library is updated or supports more stuff but specs should stay frozen. we had profile levels since forever for videos and hw decoding limits compliance for images

there's 0 chances there will be a completely backwards incompatible update to the png spec 🙂

the breakage will occur when web services start generating only 'png v3' and force everyone to update their own libraries. we already saw that with uhdr (google tried shaming software makers by calling anything that didnt add support 'naive/legacy readers'

Would be possible in 2040s

> As a quick side note on that: I want people to think about their storage and bandwidth. Have they ever hit storage/bandwidth limits? yes > If so, were PNGs the cause? yes > Was their site slow to load because of PNGs? yes > I think we battle on file size as an old habit from the '90s image compression wars. Back then, we wanted pixels on the screen quickly. The slow image loads were noticeable on dial-up. So file size was actually important then. But today?? We're being penny-wise and pound-foolish. wrong. I still regularly get less then 1mbps down when im outside because signal is so bad

I **hate** takes like these so much because they ooze of ignorance

im glad everyone lives in a first world country and has great internet in every single place they will ever be

idea: have browsers update their cache-ing systems to cache files/data as received in their compressed form from servers then websites can simply ship "uncompressed" PNG files to users and benefit from improved compression without breaking backwards compat :)

[av1_omegalul](https://cdn.discordapp.com/emojis/885026577618980904.webp?size=48&name=av1_omegalul)

1000% idea no one will complain ! (except when their hard drives fill up from downloading 10 PNG files)

Uncompressed PNG could be as large as BMP

would be slightly larger because of the container overhead

gainmaps arent the win people think. all it means (for jpg and png) is that hdr-like data will be available without making the files much larger in filesize - hardly a win since a big complaint about those was their inefficient compression compared to the storage consumption

wether with true or gainmap hdr, jxl would trounce both at lossy and lossless at consistently half the filesize

QOI is a good alternative if sizes don't matter

imo gainmaps are one of the current most important technology for HDR adoption

finally

QOI is no longer an alternative because FJXL just killed it, and is now built into libjxl as -e 1

They are certainly the way the big players are going. In my opinion though, it will mostly cause the transition to be longer and more painful. At some point, if you want to render HDR, you just need to get it done. Graceful degradation provides an excuse to postpone it, since you can be lazy and nothing will break. Gain maps make being lazy easy while making things unnecessarily complicated if you don't want to be lazy. That's a recipe for a protracted transition period where images will be rendered inconsistently for maybe a decade or two.

what's the point of ZSTD in terms of improvements. It's a direct alternative to deflate which is in png. It's faster, it's not so better. To save PNG, you probably need to take the most powerful one that has good support, parallelism, like LZMA2 Now look at it from the other side: why try so hard with old PNG if you can just use WEBP which also has full support everywhere, and compresses much better with its VP8L algorithm

-- if you want to compress 16 bits-pixel as much as possible then why not choose jpeg xl

"TakeRep" command returned an error: strconv.ParseInt: parsing "if": invalid syntax

We're pretty peaceful comparing to https://www.phoronix.com/forums/forum/software/programming-compilers/1555914-png-spec-updated-for-hdr-images-animated-pngs

> [WebP] lumps lossy and lossless into the same format, which means that, for practical purposes, in a world full of non-technical users and amateur archivists who don't want more work made for them, its lossless mode may as well not exist. (i.e. If you see the WebP extension/icon, you wind up just assuming it's in lossy mode. EDIT: Just like JPEG... yes, JPEG has a 100% quality mode with terrible compression.) are they mixing up JPEG-LS and q100 JPEG?

there's a lot of people that just assume "q100 JPEG = lossless" and in a lot of cases even use it as an intermediate format due to this assumption as well

people also forget that webp has a transparency layer, which can also be in lossy compression. This is the ultimate. the best of both modes. png and jpeg separately do not have this

the era of picture-stickers has arrived

Which is why we wanted to enable RGB encoding at. q100, to either make it closer to lossless or discourage using it due to higher filesizes

no yuv444, no interframe compression, no HDR and 10+ bit. Is it true that if WEBP had all this then all the others would be doomed? 16k x 16k limitation... one format to rule them all

AVIF has all this... and where is it? oh yeah... even webp can be read from top to bottom block by block.

apparently jpeg xl is the best...? what do you mean there is no animation compression between frames? aren't you based on the video codec ?! pfff

maybe people don't need 10 bits, hdr, or yuv444. is it possible that we stuck here on 24 RGB because that's enough.

does anyone have statistics on how many JPEG images on the internet are compressed not in yuv420 but in yuv444? <:SadCheems:890866831047417898> what will I see there? ~0%?

Nearly all tools use the defaults, so 420. We want to change that in jpegli, and even adapt to 420 based on quality, but I'm not 100% sure if we have it implemented correctly for the API

I want to write a proper program using cjpegli's API and combine it with sharp yuv one day

should be possible in theory

iirc afaik it depends on the order in which someone calls API functions as to weather or not the auto switching stuff works with the way we did it although idk if there is a better way

https://github.com/google/jpegli/pull/136

https://github.com/google/jpegli/pull/137

I thought libjpeg changes chroma subsampling based on quality level?

Oh wait I'm thinking of the CLI

maybe the API is different

you can say it straight, i've been using it for a long time, but all i see is an increase in quality on the UV channels, so why is it being presented as a new technology ? it's true that jpeg doesn't have it, but it's always been in AVC & HEVC and i actively use it in my av1 fork through many iterations of CfL

I tried looking, but the codebase is monolithic, with readability rivaling libjxl. One idea is we figure out what happens when subsampling isn't specified in the API, and do like libjxl with a -1 default which runs our auto code, that can be overridden

Shouldn't be too hard, I had a few moments of clarity where I almost understood what I was doing with the API/CLI

Then we could wedge it into the API handling code so that ordering doesn't matter

I should learn how to compile more complex things, like libavif with sharpyuv and multiple encoders to learn the ropes properly

it getting a bit tiring having to scrounge around for avif binaries to see the latest AVIF advancements

for the folk I deal with its the chicken and egg problem. gain maps are a blunt force "just take both the chicken and egg and just do it"

Is it just me or is the wikipedia article for UltraHDR ridiculous and hilarious

I really hope this format never takes off. No software supports it now or in the foreseeable future and it's just a JPEG with a 2nd JPEG in an XMP metadata tag

agreed. its heavily pushed but still has all the flaws of jpeg

Whoops, I mean, it is literally just concatenated onto the tail end of the JPEG

https://www.cipa.jp/std/documents/e/DC-X007-KEY_E.pdf

Like so

This is the most brainlet format ever conceived

camera apps with uhdr variants just give it lesser bitrate (gotta pretend if more efficiently stores images but starve it of bitrate and photographers will riot at believing lies that outrageous), no lossless of any kind, no layers at all, alpha transparency

I can't imagine it will ever be supported by any software

I think it should be considered a bug to output this format

It's like a troll format

image readers eventually will, if just cuz its pushers actively work with big companies to get it adopted

It would be like if Microsoft made a "supra HDR" that was just a new version of BMP

it shouldnt become *the norm* at least - this is another reminder of how EEE works in the opensource world

make your proprietary version that you control the default, and through forced/auto updates you can force the world to adopt and update it even if future versions are known to be harmful

producing excellent software only through an 'as is' basis does not get it adopted properly. big vendors need forms of guaranteed support and assistance and format specs are the most sensisitve that require the most flawless and well thought integrations (ie dng 1.7 and presumably upcoming pdf/tiff-ng)

I don't think anyone is going to adopt this... everyone is just going to be really pissed that their HDR images are just SDR JPEGs that nothing can decode properly

The effort they spent plumbing this new useless format could have easily been spent plumbing in libjxl

Already JXR

Ah that's right...

well JXR is an actual format with it's own core features so it has that going for it although it's always suffered from having a mediocre implementation so who even knows how bad or good it *can* be visually or compression wise and such

Is it ever able to outperform libjpeg-turbo?

It's kind of surprising that it's so bad

Yes it looks like some chatGPT nonsense tbh... Like this: > Ultra HDR format is an enhancement of conventional HDR, where gain mapping technology allows further pushing the boundaries of existing HDR.

Yeah it tells you close to nothing about it and just looks like some bizarre corporate babble

UltraHDR is not an enhancement of conventional HDR, it is a trade-off to sacrifice HDR fidelity and compression performance in exchange for graceful degradation.

In that sense the name is quite poorly chosen since there is nothing "Ultra" about it.

I've heavily disliked the name since I first heard it with the context of what it was actually for

So it's more accurate to say it's "a compromise and half-measure of conventional HDR"

Actually it's not given any reference

Feel free to remove

what the fuck is this article?

the entire thing ought to be deleted

this is a list of everything correct in the article * However, not all displays can render the full capabilities of HDR and Ultra HDR formats * To overcome this issue, a tone mapping technique is used to adjust the brightness and contrast to match the quality of capable displays ** HDR has the capability of recording a much wider color gamut in comparison to a traditional 24-bit RGB (SDR). -- (maybe accurate in some cases) --

>RBG Model yeah 100% confident this was AI

It requires to be rewritten not deleted

hows this for a review? ``` The overwhelmingly vast majority of this article is wrong. UltraHDR is a technically inferior format to "traditional HDR", not an enhancement to it. It takes an SDR image and applies a gainmap to it in order to make it an HDR image. The primary concern of the image format is to increase compatibility of HDR imagery with legacy systems. It is on nearly all technical levels inferior to traditional HDR images with the sole exception of support in applications and hardware that do not support HDR imagery. HDR10 is not limited to 1000 nits nor is it limited to DCI-P3 colorspace. ```

On Wikipedia it just requires references to prove

The article is mainly written by User:Chae07

Mid Dynamic Range

Mediocre Dynamic Range

Although not obligatory, the way UltraHDR is commonly used (with a downscaled gain map) they are effectively doing Luma Subsampling. At least for the msb of the luma.

InfraHDR

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

Someone got the courage to remove them all

with a comment > everything past the lead appears to be nonsense

"incompatible decoders"

at least they didnt use even more charged language like non-mediocre, naive, legacy

There should be an article about ISO 21496-1

and then Ultra HDR doesn't require its article

yeah <@272986016242204672> did it

I probably would have used applications instead of decoders

A related fix from PowerToys v0.92.0 > Updated QOI reader so 3-channel QOI images preview correctly in Peek and File Explorer.

<@272986016242204672> 👀

[gunthonk](https://cdn.discordapp.com/emojis/865117245013098547.webp?size=64&name=gunthonk)

https://netflixtechblog.com/av1-scale-film-grain-synthesis-the-awakening-ee09cfdff40b

interesting read on Netflix using FGS in production

Oh, so I was right when I watched a movie earlier and thought it seemed extra grainy

x264 also does that, though...

Turns out Adobe are using v0.9 or earlier for their SDK... I wish I was surprised https://github.com/libjxl/libjxl/issues/4321

> Additionally, synthesized noise effectively masks compression artifacts, resulting in a more visually appealing experience. 👀

It's effectively dithering for video, since they refuse to add it on decode for whatever reason

No, it's more than that. It does more than breaking up banding artifacts. The noise signal is also a mask that helps break up the outline of other DCT artifacts.

DCT artifacts tend to contain a lot of high frequency noise so they are masked very effectively by blue noise.

> Currently, we lack a dedicated quality model for film grain synthesis. The noise appearing at different pixel locations between the source and decoded video poses challenges for pixelwise comparison methods like PSNR or VMAF, leading to penalized quality scores. Despite this, our internal assessment highlights the improvements in visual quality and the value of these advancements. So in other words we don't have any objective metrics that accurately reflect the obvious improvement in quality. All current metrics think it's worse because they're easily tricked by random noise and think it's important for the random noise to exactly match in the spatial domain rather than frequency domain.

Noise synthesis at significant strengths pretty much always significantly harms fidelity with current implementations. And the generated noise is also of completely different frequencies than the source noise. And introduces patterns. But yes, current metrics are also generally poorly suited to reflect the perceptual effects of noise.

But DCT quantization itself is pretty good at preserving noise even without noise synthesis.

A lot of quantizers simply blur and eliminate noise by rounding down or zeroing out high frequency DCT coefficients when they could just as easily just use coarse quantization to preserve a more grainy appearance and take advantage of the masking effect

https://www.techradar.com/pro/british-startup-claims-to-have-developed-tech-that-can-deliver-65-lossless-file-compression-but-you-will-have-to-pay-for-it

> The startup highlights several features intended to set CompressionX apart, including GDPR-compliant archiving, XChaCha20 encryption, and compatibility with .zip and .7z formats. > > While this might suggest it is among the best file managers for handling compressed content, many of these capabilities are already common in mature tools such as WinZip, 7-Zip, and PeaZip. > > Whether the software genuinely delivers market-leading compression or simply repackages existing solutions with fresh branding is something only long-term use and independent testing will confirm. Nice to have an journalist that knows what's already out there

No clue what they mean by "65% losless compression". On what? Images? Because you can't lossily compress arbritrary data, and the compression depends on the content

Finally HDR 2

What a difference?

Its joke

I’ve been trying out JPEG 2000 vs JPEG on https://x0.at/qIo3.png (to test which one would be better for scans inside a PDF), but it seems JPEG just works better for high quality, whether at full size (which appears to be 1200ppi) or downsampled 50% (to 600ppi)

(I’ve been using OpenJPEG and Grok, the latter apparently originating as a fork of the former)

I thought you meant you were making JPEGs using Elon's Grok AI for a second

Jpegli I assume?

actually even libjpeg-turbo

jpegli seems to blur the image slightly more

Grok = https://github.com/GrokImageCompression/grok (AGPL)

That's probably due to this (Ignore the RGB part) <https://github.com/google/jpegli/pull/137>

it was with #130 applied

(I was a bit lazy to apply the split PRs)

Ah right, hmm. I know the jpegli decoding has a slight blur to it, but I wasn't aware of it during encoding too

`avifenc`: ``` WARNING: --min and --max are deprecated, please use -q 0..100 instead. --min 0 --max 63 is equivalent to -q 51 ``` what

lol

now it's just `-q`

interestingly, at ~0.53bpp, AVIF degrades better than JPEG 2000 but not as well as JXL (at least in my attempt)

can’t wait for JXL to be in PDF

and better to use with `-a tune=iq` (it will be the default setting in the future) like `avifenc -q xx -a tune=iq -s X -j X` + `-a screen-detection-mode=2` if there are images where sc is beneficial, this is sort of like patches and a reduced palette

What distance was the JXL at?

3.89

Ah right, wondered if my resampling tweaks were playing a part

Is there any possibility for Avif inside pdf in future?

absolutely zero, im convinced

https://pdfa.org/pdf-moves-ahead-with-hdr/

inserting as file such as archives could be possible like in .doc files but they wouldnt be rendered or parsed in any way as non-standard

jxl is a true image format and massively futureproof. aivif didnt suit even today's needs and video-based formats add complexities due to requiring bitstream refreshes based on newer major 'versions' of the codec (youd end up required to support multiple generations in addition to abandoning the oldest ones someday)

huge for archival: reversible lossless recompressing of existing jpg images to jxl (unique to jxl- normally lossless recompression causes filesizes to multiply, and lossy doesnt event guarantee smaller filesize unless you sacrifice even more quality until you hit a smaller target filesize)

I found their patent https://patents.google.com/patent/US10700701B2/en?q=(%22sisp%22+compression+algorithm)&oq=%22sisp%22+compression+algorithm

`-a tune=iq` indeed seems pretty good, thanks

(not that I have any use for avif here, but good to know)

> New tuning mode `AOM_TUNE_IQ` (image quality) for the `AOME_SET_TUNING` codec control (`--tune=iq`) in all-intra mode. […] The image quality optimizations in `AOM_TUNE_IQ` were developed by using the SSIMULACRA 2 metric for guidance and validated with subjective visual quality checks. oh, yeah, okay

it suddenly makes avif so much more competitive

(still not sure how I’d choose a cq-level, though, so even then, I’d be tempted to first use `cjxl -d 1` and then target a similar size)

yeah, it's <@297955493698076672> work https://discord.com/channels/794206087879852103/805176455658733570/1375999430456508456

just `-q`, like cjpeg `-quality`

no more need for that `-q 0..100 -a end-usage=q -a cq-level=<quality you want>` dance?

yup

that's been the case for a while, fwiw

yeah, the other stuff is picked automatically `avifenc -q "quality" -a tune=iq -s "preset" -j "threads"`

how reliably does a given `-q` match a certain image quality across images?

this is where I’m not sure how I’d choose a `-q`

there is some mapping for `--min --max`, but some -q values doesn't work, like every second one works, the other one is the same as the previous one or something like that as I recall, so it's not very accurate but easier to use

yeah, tune iq is the port of SVT-AV1-PSY's "still picture" tune that <@703028154431832094> and I worked on

well, congratulations, I’m impressed

thanks! it's even more special coming from a JXL dev 😄

`-q` levels track much more closely with perceived quality across images with tune iq (compared to the current default, tune ssim)

the value itself isn't normalized to any metric

I'd recommend testing `-q` with a small image corpus in increments of 10

the usable range IMO is 40 to 90

btw I'd do `-a c:tune=iq` so the tune isn't accidentally applied to alpha

it's 64 AV1 CQ values mapped to 101 [0-100], so some will be duplicated

it feels a bit odd that `avifenc` and `avifdec` are used so differently

`avifenc input.png -o output.avif`, but `avifdec input.avif output.png`

`avifenc` accepts `--no-overwrite` but `avifdec` doesn’t

Oh that reminds me, I was messing with cjxl parameters last night and realised `--centre_x` and `--centre_y` don't work with chunked encoding

Surprisingly `--group_order ` does work, which is centre first, but adding the others causes it to use scanline instead unless using effort 10, ect

I wonder how much JPEG 2000 could be improved using a similar approach

today’s testing did not leave a great impression

There were whispers of improving JPEG XL with the same techniques. Jyrki does well, but is only a single man at the end of the day

that could be interesting

on this test image with jxl, I’m a bit concerned by the purple tint I am noticing in the dark areas

seems to happen even at d0.1

correction: not dark areas, plural, but the specific dark area I was looking at (left of Jolteon’s face)

Could you send a closeup of the area?

wait, I don’t see it here

ugh, is this a quirk from the comparison tool, maybe in combination with my monitor profile?

How are you viewing it? The tool in libjxl?

yes, the `compare_codecs` tool

with the jxl loaded as jxl

oh, wait

it’s only with https://github.com/libjxl/libjxl/pull/4325

so I guess it’s faster but less accurate then

Ohh, that might be why some applications/CDNs give XYB JPEGs purple color bleed even when converted to 'sRGB'. They're not accurate enough for the conversion

yeah, maybe, I just remember that avifenc also gave the same size images when I was doing some comparisons though, maybe it was before the q changes

It says both avif and jxl on pdfa org 😶

Kakadu is supposed to be a lot better than OpenJPEG. I think OpenJPEG has no perceptual encode mode at all, just psnr

Could I ask why applying `tune=iq` to alpha be problematic? And which `tune`, if any, is best/default for alpha? (I also find `tune=iq` a massive improvement over `tune=ssim` 🙏 )

https://github.com/AOMediaCodec/libavif/pull/2830#discussion_r2155240594

because alpha isn't amenable to be encoded with psychovisual optimizations

but this does have a more comprehensive explanation

Sorry for a flurry of questions, <@297955493698076672> (I’m trying to get `iq` the default for the site, tests are extremely encouraging, most overcompressed images look much better and the savings from undercompressed ones, which look more or less the same anyhow, offset that increased weight nicely; given same quality setting on a largish corpus), but I can’t find an explanation of how to specify tuning for different planes (`c:tune=`)… How to specify `psnr` for alpha, so that it works both before and after PR linked above is merged?

you can keep using the default tune (ssim) for alpha

c: stands for the YUV planes

so you're just overriding the tune for those YUV planes

after the PR is merged, you won't need to specify any tune at all

Ah! [Here](https://man.archlinux.org/man/avifenc.1.en#AOM-SPECIFIC_ADVANCED_OPTIONS). So if I would like to be explicit, I would go `-a c:tune=iq a:tune=psnr`.

correct!

Anecdotally (and admittedly my corpus is smallish, I do tests half-manually), I would love `tune=iq` to be a lever which I would crank harder (I would like poor-looking “LF” images to go even larger and already good-looking “HF” ones to decrease in size even more; and for the effect to be even more pronounced the larger the image dimensions). But the switch from `ssim` to `iq` is transformational already. EDIT: And, thinking about it, one could replace “images” in above sentence with “image areas”, if one was dreaming.

<@810102077895344159> if you can build from source and want to experiment, you can change the scaling of Variance Boost to make it stronger (all_intravis.c, line 1111): ```c int boost = (int)round((base_qindex + 544.0) * (base_qindex - target_qindex) / 1279.0); ``` to something like this: ```c int boost = (int)round((base_qindex + 544.0) * (base_qindex - target_qindex) / 800.0); ```

there, this should be quality-neutral: https://github.com/libjxl/libjxl/pull/4326

ah, right – too bad that the licensing is such a pain

https://scispace.com/pdf/jpeg-vs-jpeg-2000-an-objective-comparison-of-image-encoding-1n02yfm70l.pdf seems to have found better performance from jasper than from kakadu

but they also noted: > For low compression ratios (below 20:1) JPEG produces slightly better images (mainly due to the greater perceived sharpness, cf. Figure 11b below), whereas for medium to high compression ratios we obtain higher quality with JPEG2000. This confirms the common observation that JPEG2000 works best for high compression ratios.

and also: > If we just consider PSNR to compare JPEG and JPEG2000, which is shown in Figure 10, we find JPEG2000 to be a better encoder than JPEG for all compression ratios. This confirms again that the MOS prediction by Image Optimacy is a better indicator of image quality than PSNR.

https://stackoverflow.com/questions/57342487/ultimate-jpeg-2000-compression > ImageMagick, GraphicsMagick, OpenJPEG all showed identical results (I assume, due to usage of Jasper to encode JPEG-2000) and all lacked options for encoding. Using Kakadu or online/basic converters didn't help either. well, all right

time to give up, maybe

kornel: > It's a mostly dead format, for a good reason. It's been hailed as "20% better" two decades ago, mainly based on flawed PSNR scores. You're not missing anything, you're not doing anything wrong. There's nothing great hidden in JPEG 2000.

JXL is the answer

I was hoping for something embeddable in PDFs, but it seems that until JXL makes its way there, good old JPEG is still the best option

~~erm but what if I want all my extra channels to be DWT compressed \🤓~~

The main thing J2K has going for it is a huge amount of features and extensions. It can do almost arbitrary bitstream reordering, it has extensions for volumetric data etc, lots of stuff. That's of course both a pro and a con since it makes it hard to really completely support all of J2K (all parts of the standard), and while the baseline codec is royalty-free, probably some of the additional parts are not.

Even some of the original J2K devs understood that it wasn't actually bringing better compression in the typical quality range, only in the range where bitrates are so low that JPEG breaks down, or in the range where you need higher fidelity than what JPEG can bring (i.e. high bit depth, lossless and lossy at q > 98). In this paper from 2000 introducing J2K at the DCC conference, they're quite clear in the conclusion: > JPEG-2000 is unlikely to replace JPEG in low complexity applications at bitrates in the range where JPEG performs well. However, for applications requiring either higher quality or lower bitrates, or any of the features provided, JPEG-2000 should be a welcome standard.

even for lower bitrates, I’m finding that a high-quality jpeg of a downsampled version of the image does better than a same-filesize j2k from the original image

That's why I briefly experimented with subsampling in jpegli, to try and recreate JXL style resampling at very low qualities, but it always came out wonky

You could potentially get the same effect by zeroing all HF coefficients

8x resampling is far too much, even 4x I ended up scrapping in libjxl when adjusting thresholds

I noticed that the native webp decoder does a very sneaky trick that no one does natively. When decoding, it natively immediately interpolates the color plane. While AVIF does standard nearest neighbor interpolation, and JPEG works depending on the decoder settings in individual applications. But this also means that, for example, if the input image for encoding is yuv420 inside PNG, then I completely lose the ability to compare the webp output with the original, because of this native interpolation and it's annoying original | avif | webp sharp_yuv | webp

well and of course I would like to say that the sharp_yuv algorithm does not work quite as I thought all these years, in fact, at quality, for example, q100, it can even spoil the picture if the input is yuv420. You know, earlier, looking at the examples, and looking at the results themselves, I thought, well, the colors became better, the image began to file size more. Apparently, they up the bitrate for color. But looking now, I would say, perhaps, probably, everything is connected just in the sense that if the interpolation is performed natively, it would be possible to make it so that the colors were arranged in such a way that after interpolation it would give more quality, like the original. This also answers the question why only Webp has something like this and why it was not implemented in jpeg many years ago. Because Webp does not act professionally here, but very clearly for a very limited type - the Internet, pictures on the Internet, nothing more.

This all leads to this question: do you know what you're doing? Will you start doing it?

and also a question -- when Webp encodes an image -- does it do PSNR an already interpolated color <:Thonk:805904896879493180> because if interpolation is unavoidable during decoding, this could provide an advantage

What is "yuv420 inside PNG"? PNG only supports RGB...

We did it a few hours ago in the voice channel, soon we'll try and integrate it properly and make a PR

yuv420 inside RGB inside PNG

AKA recompressed 420 in a PNG

successfully?

because i can't just open webp and see how it works pixel by pixel. extracting UV channels. i'm curious how it looks in practice

due to interpolation on decoding

<@207980494892040194> you still got the test encode?

Yeah it works well

Do I know what I'm doing? No not really. I'm learning as I go. That's the fun part. Will I start doing it? I have proof that it works at least. It will be ready when it's done. I have college and a job that requires my attention first and foremost.

Were u using dav1d?

Mpv on mobile

Hmm

Updated

Anime 1080p 24 fps plays fine

But minecraft content 60 fps dont x)

https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=168126

Meta is attempting to look into this I guess

AMA

Wow! Good work tuning WebP for ssim2! I have a few questions. Considering webp only has 420, what is the baseline ssimulacra2 quality for 0%? 75? 70? Does this extra quality come with a performance cost or was it just a matter of using more effective/efficient algorithms? Does sharpyuv play a role here?

420 and 8bit only were huge limitations but this is still impressive

few misc questions: 1. Has there been any tune-ing or handling or otherwise done for image data that goes beyond sRGB such as P3? 2. Is it heavily modified version of libwebp or an encoder from scratch or something else/in-between? 3. Not really a specific question but what features of VP8 where taken advantage of or tuned encoder side?

libwebp seems to be extra bad when it comes to P3 so I'm curious if iris has any sort of tune-ing or otherwise related to such images or if all testing and tune-ing has just been done against sRGB data

oh I guess another question: 4. What is the availability of this gonna look like? the website screams to me that it's gonna be one of those things your gonna need to contact and pay for kinda like [Kakadu](https://kakadusoftware.com/) or [Bink](https://www.radgametools.com/bnkmain.htm)

> Good work tuning WebP for ssim2! heh i feel like this is like saying "SVT-AV1 is AV1 tuned for VMAF" but thanks I guess. fwiw, Iris is a bespoke implementation in a number of ways, and does well on Butteraugli too > Considering webp only has 420, what is the baseline ssimulacra2 quality for 0%? 75? 70? for this particular graph, its around 0 to 80 (just for the sake of demonstrating encoder performance). however, Iris is competitive at much higher fidelity; a lot of the hurdles that libwebp faces with higher fidelity have been overcome, in my opinion. it has been really hard, but it is very important to me and many of us here > Does this extra quality come with a performance cost or was it just a matter of using more effective/efficient algorithms? Does sharpyuv play a role here? the graph I'm sharing is speed-to-BDrate, so for any given speed, Iris should be better than libwebp on average. our slowest mode (speed 0) is actually faster than libwebp's slowest (m6) while being much better looking, while our fastest mode is faster (speed 6 is more comparable to m0 using the encoder binaries, while speed 7 is faster). I won't speak to algorithms, but there is a lot of new research in here that isn't seen in libjxl, tune iq, or other video/image encoders from what I've been able to observe

> Has there been any tune-ing or handling or otherwise done for image data that goes beyond sRGB such as P3? honestly, not really yet ... currently things should generalize well (I don't see why they wouldn't outside of HDR, which WebP doesn't support anyway) but if they aren't generalizing there will be work put in there > Is it heavily modified version of libwebp or an encoder from scratch or something else/in-between? I won't say too much, but it is something in between > Not really a specific question but what features of VP8 where taken advantage of or tuned encoder side? i don't want to disclose my exact methodology, but VP8 in particular doesn't have the biggest set of coding tools compared to AV1 where you have a lot of decisions that you are able to make (420/444, 8/10bit, etc) > What is the availability of this gonna look like? the website screams to me that it's gonna be one of those things your gonna need to contact and pay for kinda like Kakadu or Bink for now I'm looking into licensing, but I'd strongly consider making this open-source because I love open source. I just need to be able to support myself while working on this

they're still really big limitations, but one of my goals here has been to try to overcome them. I think it isn't impossible, despite what the discourse has been for a while

its worth noting that grainsynth hits really bloody hard on arm devices if you don't have that either disabled or gpu accelerated

Would there be a point in considering something like this for grayscale images as well? Or did you primarily optimize for color?

im not "optimizing," im building a new encoder, which involves making generally good decisions. some will benefit luma, some chroma, some both

> heh i feel like this is like saying "SVT-AV1 is AV1 tuned for VMAF" but thanks I guess. fwiw, Iris is a bespoke implementation in a number of ways, and does well on Butteraugli too At least ssim2 has a much better reputation than VMAF. Sorry if that came off as dismissive 😅 , I know you are doing much more than just tuning for metrics, it's really cool how much more you can get out of 8-bit 420, disproving the idea that it can't reach higher fidelities. Speaking of the website, are the WebP images present in the website encoded with Iris or libwebp? I also noticed you distribute jxl versions for compatible browsers (hell yeah <:JXL:805850130203934781> ). These jxl versions are more vibrant with more contrast than their WebP counterparts, is that intentional? Any ideas/plans for the future, what's next? (Iris or otherwise)

OK. I would suggest setting up a way for people to try your encoder, possibly through an upload form

yeah ICC profiles got messed up. those are encoded with an early version of Iris that represents ~50% of the gains we have realized today (I should probably reencode them, but it isn't the end of the world)

plans for the future include making Iris-WebP better; includes speed, quality, etc

ill think about this, but I like having a static site, and I don't really care about community feedback (no proprietary encoder developer does, really)

avifdec decodes to RGB...

and what does this mean? who doesn't do this? the image on the monitor is RGB

anything that uses avifdec instead of decoding the raw AV1 stream in the AVIF container should not have to do any YCbCr to RGB conversion.

This doesn't sound like precise knowledge, and what is it supposed to mean? I don't understand.

I don't understand at all what this has to do with it, what it's for, what it affects in the conversation about the webp decoder doing color interpolation natively

<:Thonk:805904896879493180>

avifdec also does proper chroma interpolation natively, that's my point

proper? I see that avifdec doesn't do it.

where do you see that?

this should be done individually by the programs that display the images

no, it shouldn't

open image and zoom in. i see subsample 2x2 yuv420

then it's not decoded using avifdec

displayed by nearest neighbor scaling

you mean nearest-neighbour upscaled 4:2:0 chroma?

☝️

implementation fault then

what

Does the avif spec define how to upsample chroma?

if the application does the chroma upscaling, it obviously is its fault for doing it poorly

Very most likely no. Avifdec actually used to support a higher quality chroma upsampling method. But then they noticed it didn't work well with "sharpyuv" (downscaling in linear light to produce the chroma planes), and removed it again. On paper, avifdec uses simple bilinear interpolation for the chroma upsampling. However, for some reason it produces better results than the bilinear upscaling I've tried...

I know that for downscaling, there is sharp (2x2 source samples) and blurry (4x4 source samples) bilinear/triangle downscaling, with the blurry method being more common in image processing.

might that relate to this? https://g.co/gemini/share/1dd0228a4251

it does not perform color interpolation, but this is unnoticeable if general interpolation is performed. But for example, if you make an increase of 1% by performing full interpolation of the entire image, it is clear that the color is not scaled separately. color decoding in the nearest neighbor mode. While Webp looks better precisely because it natively performs interpolation...... There is a completely logical answer - AV1 as a codec has YUV420 native decoding, while displaying video in the buffer, all media players, mpc-hc vlc mpv have parameters for separate interpolation of Y and UV channels. It works in the browser in the same way

neural answer bruh

is it inaccurate?

MPV has --scale (Y+UV) and --cscale (UV separately)

I didn't read, too much text, which I don't even trust. No respect for such an answer.

besides, I gave my answer

I read it and it seemed plausible

since I have a lot of experience watching videos that are very lagg on a smartphone or computer, changing the scaling type can greatly affect performance and for example there is such a thing as BICUBLIN which does "Select bicubic scaling algorithm for the luma component, bilinear for chroma components" just for these cases

I think not specifying what upsampling to use is a mistake. An encoder needs to know what a decoder will do.

But it's not surprising. The video codec philosophy has always been "we just compress matrices of numbers, how to interpret them is not our problem"

I mean that the video is made in such a way that there is a 90% chance that it will be scaled. There are only 2 cases when it is not, a 1280x1024 monitor for viewing 1280x720 video and 1920x1080 for the same size. Everything else will inevitably be scaled, and in all video codecs this is done at the decoding level when the data is still in YUV444 on all components. BUT when you take an image, this is suddenly a problem. This is not a problem if it is a heavily compressed JPEG. But for example, AVIF q0 yuv420 has a problem, how to decode it? And WEBP decided not to ask, but to do interpolation. Because AVIF is literally the first frame of AV1 without exceptions. And WEBP is a completely independent format. I confirmed this fact quite simply by opening an AVIF yuv420 file in the MPV player -- UV Chroma interpolation is present there. While XnView and PaintDotNet do not do this.

<:SadCheems:890866831047417898> puzzle is solved👍

Sorry, didn't read properly, but sample position is a non-issue with still images, it's always center there. Actually, if an application extracts the raw AV1 stream instead instead of using avifdec, whatever does the upscaling might assume left position 🫤

perhaps that's fair, perhaps...

color interpolation has always been done, but it can be so subtle that we don't even notice it

even with 1920x1080 video, which is perfect pixel for pixel on your monitor. this is actually a lie, because the color is 960x540 that needs to be interpolated, and if it is bilinear, it can give worse quality, and there will be noticeable blur

It's a classic engineer trick to formulate the problem in such a way that it becomes easy to measure performance of a solution. Color spaces and image quality are messy stuff, just computing the PSNR of an array of numbers is easier.

from my experience I could say this - if the image will be scaled up 2 times or more from the original, it is better to use PSNR. and if not, then SSIM is better. At 1280x720 SSIM is better and at 640x360 PSNR is better - it is impossible because the image will be scaled up many times more strongly

since I am the only person on the planet, besides the AV1 developers, whoever tried to compile AV1 Butteraugli, I can say that encoding is so unimaginably slow, and the result is so small advantages (but it is there) that perhaps we will forever remain in SSIM for video

also, i see a big problem with this approach in jpeg XL. if you scale the image, it looks very problematic, but if you look at it as intended, pixel in pixel, it looks very good

Hmm, I suddenly became interested in whether this problem can be solved <#848189884614705192>

AV1 butteraugli was never meant for video 😄 butteraugli doesn't model a lot of the video effects

I don't see a problem with that. Video is still a lot of frames. Just like SSIM, there is no "time frames" coding or anything like that Moreover, I saw with my own eyes small quality improvements. But as I said, they are so insignificant, like a more correct line shift by 2-4 pixels along the original location vector. That it's all useless. It is much more profitable to use SSIM but increase the preset to get better quality. Since butteraugli takes power like 2-3 presets down

This will probably give an advantage on the slowest possible preset, but Netflix invented VMAF specifically for this purpose.

have you tried the new `tune=iq`?

no. I have my own fork. I recently tested comparisons with version svt-av1 3.1.2 and came to the conclusion that what I did a year ago is still better than what they do with AV1

the main problem is that AV1 is more dead than HEVC, it's annoying

I have literally just mentioned something new in the AV1 world?

you just immediately dismissed it

you seem adamant that what you did a year ago is better than this thing you haven’t tested

In my world there is only tune=0 tune=1 tune=2

I am adamant convinced that it is impossible to make 10%+ better with one tune, in a year, with identical encoding speed. Practice shows that this is an impossible achievement for a codec that is already 7 years old.

didn’t jpegli do it for a 20+-year-old codec?

`The Joint Photographic Experts Group created the standard in 1992`

guetzli release 8 years ago

then same question for guetzli?

but also, that’s clearly not “with identical encoding speed”

not so long ago

the goalposts seem to be shifting

ok, what do you want to hear? is there any example other than jpeg? mp3? vorbis? png? webp? AVC? vp8? vp9?

well, maybe `tune=iq` for AVIF?

Okay, let's. Under Av1 specifically AOMENC?

yes

ok, i'll do some tests and compare with my fork

it is unfortunate that this is the reality when video codecs become image codecs almost as an externality. ideally there are some encoders that can consider this, but they'd be held back severely by inconsiderate scenarios like this

esp w/ regards to decode

The first person to solve a problem is usually the one to consider that "impossible" might be possible

basically all of these formats got better encoders only after some time even like an old and at first glance simple png

“they didn’t know it was impossible, so they did it”

how many encoders for webp? and for jpeg xl? and for vp8? flac? Sometimes there are just no studies, no interested parties, to do everything from scratch, solving possible current fundamental problems. The fact that av1 has many codecs is nothing less than a miracle. But this does not mean that its the best of all possible

The number of encoder implementations does not mean that much imo. The important thing is if there's a good one available for free.

libjxl is still getting better – are you saying WebP/VP8 has hit its ceiling?

not work in ffmpeg

even the same encoder at the beginning and after some time very different vp9 was at first like 100x slower and worse quality, even considering it's still not very good, but such not very popular formats didn't last long, so people and developers quickly switched to other more promising ones, but there is still a lot of room for improvement vp8 also, it was much, much worse on release, as was lossy webp, it only got better over time x264 for avc made a big leap in quality, although even x264 was not immediately good, it took a long time lame for mp3 etc there are new more efficient or super fast encoders for png that didn't exist before, although it's a very old format where it seems hard to improve anything

Webp is the main format of the Internet besides Jpeg. It is actively being improved. But one can say unnoticeably. Nothing global. vp8 is simply dead. It simply died right after the release of vp9 because the realtime preset makes the existence of vp8 meaningless

vp9 is still worse than hevc at the same video size and encoding speed. except for the realtime preset cpu 8 and minecrat

even if vp9 is worse than hevc, still the newer versions are better than the oldest ones

libvpx* is worse

WebP in general, or just libwebp?

and these are already facts, and will not change. the potential for development and improvement due to the prostate of the codec turned out to be not so much realizable after 10 years

that’s actively disproven by eve-vp9

great scam

okay then, I don’t see this conversation going anywhere, I’m gonna leave it here 👋

lol what? you're just going to leave? have you seen the screenshots on eve's website? i saw them 5 years ago and they were claiming quality that AV1 still can't reach on its slowest preset

not only have I seen the screenshots, I worked on eve myself

I don’t feel like elaborating if you aren’t going to ask meaningful questions, so again, leaving it here

No thanks, it's a business, and their job is to sell their product, to foist it off. Never, never said: damn, why do we even need AV1 if there's eve-vp9 which is much better.

because eve-av1 is even better <:kekw:808717074305122316>

so is this rofl or trolling?

it doesn't, unfortunately

like "objective tests"

no, eve-av1 is better than eve-vp9, and again, formats and encoders are different things even if eve-vp9 is better than open source av1 encoders, it doesn't mean eve-av1 can't be even better

really a masterpiece image that i saw in the article about vvc. This is the peak

ok ok. Let's do it this way: I can admit that eve vp9 is better than libpv9 eve av1 is better than svt-av1 But what they show on the site and in tests is a lie. I have been working with this for too long to say -- no, this codec can't do that, no way, this is a lie to sell your product, this is false advertising and tests, this is business

although I also have no proof, but theoretically and also considering that open source encoders are usually not the best encoders (with some exceptions and because we are used to x264 being the best for a long time) so why not, although there is always some marketing exaggeration, but it is not something impossible, vp9 and av1 are still very far from their efficiency limits

<:SadCheems:890866831047417898>

> vp9 and av1 are still very far from their efficiency limits This is blind faith

x264 didn't become the best yesterday, it's been like that for about 10 years

That's the exception, not the rule. Most formats used today are not using 100% of their potential.

i said the same thing, encoders and even decoders have a very large, even almost infinite potential for improvement and if the formats are modern, then this is still a very early stage (vp9, av1 are very recent, modern formats) and even now and in another 50 years, it is still possible to improve some old formats, even jpeg can still be improved even more, it is more difficult each time, but possible i do not even take ai, for example for a decoders, because it is an endless abyss of possibilities

vvc <:kekw:808717074305122316> forever the meme codec

slower than aom and barely anything native can even play it

Region Of Interest encoding my beloved

original | my fork | your recommendation (aom -s 0 tune=iq)

Well, what can I say, yes, there are details that my fork doesn't have. And there are artifacts that my don't have.

I see that in this mode, unlike SSIM, AOM try to preserve more low frequencies, at a cost that I consider unacceptable.

meanwhile proper avif with native libs from xl-convert

444/q80/bd-10/regular tune

420

blame discord for that

point is avif ='s and sometimes even surpasses jxl

I see that tune=iq is better than just AOM . but it is not better than my fork. So I am still not happy

bruh its dang near identical to the og img wdym 🤣

without tune=iq

independently of the truth value of that statement, I’m not sure a single screenshot with no bitrate information does much to corroborate it

true (but try it and see metrics) have noticed that jxl tends to smooth just as much if not more than avif depending on the content, img viewer, instance-to-instance lib imps etc

Nah, I'd won

doesn't help that discord converts basically everything to webp 420

Arguably that's been happening since v0.9, when encoder heuristics were replaced and larger VarDCT block sizes became more common

yep constant issue with the forks of av1

superblock errors i like to call em 🤣

funny, this is exactly what I was solving as the main problem of my fork

VarDCT block difference https://discord.com/channels/794206087879852103/1278292301038227489/1297641489240817734 SSIMULACRA2 scores https://discord.com/channels/794206087879852103/1278292301038227489/1309307664387276820

such fine art xD

<@604964375924834314>I don't know in general... here are my arguments, and a picture, can someone create AVIF of better quality than mine? I don't know... AOM is not capable, even with tune=iq

it clearly is tho

even on weird tests kek

Seems to me like it's more biased to "Are there identical block sizes that can be merged" rather than "Are these blocks correlated" since v0.9

💀

We planned to do some tests reverting the change or tweaking values to their previous states, but we've been too busy lately

yee can kinda see that happen in my above weird example

altered the top left greens color

Encoding that image as a JXL might actually show another issue with the encoder lately. Desaturation in high frequency vibrant colors The AC of the B needs to be boosted like Jon said previously, but that requires making new quant tables for the first time instead of using the spec defaults

Am I right in understanding that there is no single general testing after each commit? That is, there is just no actual tracking like "libjxl versions quality graph" built into the development?

yea can see it primarily in the pure noise at bottom right

but def the top colors as well

They were based on your complains about image quality, but on that fateful day, you decided not to test... https://discord.com/channels/794206087879852103/794206170445119489/1159227239024566394

I've been on the server for 3 years now and this is the problem that is the most important, but for some reason no one sees it. What's the elephant in the room. Am I the only one who sees it?

I can notice it too, but apparently others in the server are less sensitive which is interesting. Jyrki asked me to have a call to discuss how to test the desaturation, but life has just been too busy to sit down and make it happen

I mean literally every image encoded in JPEG XL vardct EVER has a problem with colors being desaturated compared to the original. All of them. And no one sees it?

https://github.com/libjxl/libjxl/issues/3616

Everything that was encoded today and day 4 years ago.

weird cause technically doesnt jxl support a higher color gamut than avif?

in fact, avif also suffers from this disease. but it is much more invisible, almost not there, but it is there. And here I have no answer. Because in Webp this problem is completely absent. But I observed similar effects in jpeg and jpeg xr

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

UV

Internally it's 32float and an absolute XYB colorspace, but the quantization is too harsh on the B channel, causing the values to raise and make the image shift towards white

it's a bit funny that the problem is easy to solve, just increase the quantizer for the UV color plane and the artifacts will become unnoticeable... wait, you have XYB..... ohuh

the problem is that fading and a general drop in color quality is observed very early, not when there is very low compression, but right at very high bitrates like d 1 or even d 0.5

https://cdn.discordapp.com/attachments/794206170445119489/1210507187320000553/jxl_animation.gif?ex=687025eb&is=686ed46b&hm=3cedd3f4f693b79756fabaa520c31ff47dcd9e2e51f4332558d2c46b54097313&

Here's the issue demonstrated https://discord.com/channels/794206087879852103/794206170445119489/1375334116102242374. The link a few messages above the comparison has a good demo of XYB, where you can see how moving the B channel slightly can quickly make it lighter

call me anytime, i'm always ready to take part in it, i want to live in the future <:jxl:1300131149867126814> <:Stonks:806137886726553651>

The benchmarks said it was an improvement in all metrics, apart from SSIMULACRA2... And our eyes...

maybe we should swap out butteraugli with ssimulacra2 for the internal metric for libjxl

I remember somebody saying it was doable