JPEG XL

done

sweet

Scrolling is still absolutely terrible on firefox on desktop

ok i'm getting rid of it

arrow keys don't work and you have to scroll *a lot* to actually move down

on MacOS chrome/firefox/safari and Android chrome it worked quite well for me, but I'll remove it if it causes trouble in other environments

please refresh, should be better now

it is indeed better now.

I'm curious: who is viewing the page in dark mode and who is viewing it in light mode?

I in dark mode

also: would be good if there were some other comments on hackernews than about the scrolling behavior 😉

maybe add other software without logos as a text cloud and link to the github list, because visually there seems to be very little support

normal scroll the comfiest

something like this?

yeah

tachiyomi has logo tho https://twitter.com/tachiyomiorg

how popular/notable is it? I think it's better to keep the logos for the more widely known stuff

yeah i can agree to that, fair

also things that can produce jxl, rather than only decode

(well except browsers of course, those are notable enough to add with a logo even though they decode only)

id include infanview too as its somewhat notable

would it also help to mention all the big companies who mentioned interest on the Chromium bug, and are waiting browsers' support to implement JXL?

some of them already started working on it (Adobe)

I got that logo from wikipedia. I think it is fair use to use it in that way

They can send a cease and desist if they don't like it. I think the main concern is if people try to claim their product is related to their products when it isn't actually

apparently it's public domain so I wouldn't sweat it.

copyright and trademark are different law branches

but it's probably safe here

https://twitter.com/DrQueuecumber/status/1593692421497319424?t=chaABtFVsqBtQhOal5svZg&s=19

Research scientist at NVIDIA is ranting about jxl/chrome

does it actually help Google's revenue to promote AVIF over JXL?

I mean they are both free and JXL can save bandwidth if they have some sort of responsive decoder

if jxl wins then usage of avif will likely be hit and thatll supposedly reduce their AV1 leverage over other players in the field

or something like that

If the browser is smart enough to only partially download images depending on desired resolution I mean, for example

What sort of leverage is there, I mean it's a free format for video meant for everyone to freely use without caring about "rights" and "licensing"

these licenses are full of backdoor conditions

which may make other players avoid doing lawsuits using patents they supposedly hold

its kinda political play and whether it makes sense or not for you is irrelevant as long as it makes sense for people who are more up in management to block jxl

id say avif's/av1's teeth there are kinda oversold anyway but that's to be expected from its authors

hence conflict of interest argument

in practice, no

people have this fallacy that AVIF's success requires JXL's failure and that AV1's success is dependent on AVIF's success both of these ideas are false but it still drives a lot of people who make decisions and have a big hand in AVIF

keep in mind that the person making the decision is not doing so in the best interest of google's bottom line. nobody makes decisions like that except people in top-level management

Honestly AVIF is kinda dumb, it's just a mp4 video file with 1 frame, and animated is multiple frames, why do we need a whole new separate format for that...

because you can't put videos in `<img>` tags

I mean I understand that AV1 and JXL are not competitors at all

But why does AVIF even need to exist at all when there are already web supported formats encapsulating av1 data

I mean AVIF is essentially just that but written down

and for multi frame animations we have <video> and loop=1

in a reproducible way

by standardizing it as an image format you can basically take already-existing technology and make it fully specified

I think that's why firefox said they will not support animated avif because it's just incredibly redundant

animated images themselves are sort of silly

websites mostly use H.264 for that

I like animated images but why create a new format that is barely different from already existing formats

that are already standardized and specified and supported

because it esentially is just that, it's just a combination of already existing technologies but fully specified

it prevents differing implementations of the same combination and increases interoperability

basically all AVIF is is that someone said "okay so we all want to put an AV1 keyframe in an mp4 container, right? Here's how you do it." and prevented fragmentation

Yeah but other formats are already fully specified and fully supported... AVIF does not need to exist as far as I can see and webp especially was stupid from the beginning and I'm surprised it was ever taken seriously

>other formats were already fully specified and fully supported

av1 I-frames were not fully specified and fully supported and used as images

Yes other av1 encapsulating formats

what happens when you don't make an explicit image format is that nobody can use it

there's a reason FFV1 is not an image format

despite being a lossless intra-only codec

because there's no specification on how to encapsulate it as an image

I mean there's nothing stopping someone from distributing single-frame ffv1 files

the thing stopping it is that nobody can read them

Anyone that can decode multi frame files can decode single frame files too...

sure, but there's no consitently written down way to deliver these

It's the same thing, nothing changes based on how many frames there are

in the real world you don't control the whole chain of flow

if you control the delivery and presentation, sure, you can do that

but you don't always control them both, so you need someone to write down standard interoperability

AVIF is just a description of that standard interoperability

You can deliver it the same way you can always deliver ffv1. Either raw or probably in a matroska container. Extension mki I think is the convention for single frame

you're just arguing that something is theoretically possible technologically

which is true

but the problem is you need people to *agree on that standard*

I'm just saying that anything with the capability to decode and display multiple frames already knows how to decode and display one frame

actually no because video is often decoded in hardware

which is completely impractical for many images

and you need people to agree on *which container* and *which restrictions*

implementing all of matroska so you can decode ffv1-single-frame-inside-matroska is not useful you need a restricted subset of matroska which is all that is required to implement ffv1-as-image

But yeah I get that it makes sense to standardize how to distinguish an image from a video and what is the bare minimum requirements to "support" a certain profile

AVIF isn't just AV1+MP4, it's specific list of what needs to be supported among those two in order to support AVIF fully.

which is a strict subset.

You're thinking from the perspective of someone who just decodes everything with FFmpeg, not someone who is a vendor trying to deal with minimal necessary-to-implement subsets

AV1 is often in matroska anyways so I'm surprised they didn't go with that instead of quicktime

they went with whatever HEIF used

Web browsers should just allow webm / mp4 in img tags

HEIF is the name of the container - HEIC is HEIF with h.265 I-frame and AVIF is HEIF with AV1

is AVIF's HEIF use the same as HEIC's, though?

i had an impression that AVIF defined some of their own stuff

and i was just explaining in broad strokes the use of mp4 as base as opposed to matroska

isn't HEIF covered by patents seems counter to an open internet smh

AFAIK they didn't want to deviate from HEIF so that everyone that already uses HEIC (Apple) can just use AVIF but only change the video codec (HEIF was specified to be codec agnostic).

but at least from my reading they did introduce some features not present in HEIF unless im misremembering

for me it kinda feels like they still forked the format even though the way its done is backwards compatible

HEIF itself isn't covered by patents, just like MP4 container isn't (only Apple had patents but they put that out to free use when MP4 was standardised). The problem with patents is only because of use of h.265 in HEIC.

didn't nokia have some patents actually touching format itself

i mean the container

i see

<:This:805404376658739230>

I wonder if we should make https://jpegxl.info/why-jxl.html the landing page of jpegxl.info and move the current https://jpegxl.info/ to a "more info" second page

Yes

i guess it would be better to just make a very noticeable link to "why-jxl" from the main page, since the current one is more compact, informative and useful

No. when people visit the site from google search results, it is better than show them what is a jxl format and it's advantages. for that purpose, why-jxl seems to be better landing page.

the f----

on non full hd screens this page looks ugly

may be change the font?

this bad design isn't acceptable in 2023

why is that a bad design?

it looks like pre pandemic, like when people eated white nutella

Can you show examples for good design?

tik tok

Try to submit a pull request

fanpage.it and twitter also improved a lot their design

is not bad

Does it? I thought I made it work well with various screen sizes...

it looks like a 2k pre pandemic site

http://mimmocavallarofanclub.blogspot.com/2011/09/ohi-peppinella.html

I don't know what you mean

use at least this pt on text

is it made with github?

iused this to read

this font has ligatures so it not bad

apparently is an issue with my font rendering

look at the J

this is way better,

in my opinion you should use a jpg xyb at this quality

here's original

That's an image with alpha, jpeg does not support that

or you do pingo -webp-palette=86.4 -nopre -s6 C:\Users\Use\Documents\s.png C:\Users\Use\Documents\e.webp

when new pingo is out

but you don't want webp

you want jxl

in my opinion you should force muli font at 52 px

Or download muli v 2.0 from GitHub

or make a 810x577 rectangle at start of the page

I also optimized image

pingo -pngpalette=31.87 C:\Users\Use\Documents\s.png C:\Users\Use\Documents\eas.png

https://twitter.com/scofrona/status/1594375052828737536?t=QQSYyOXAbhWvHHZSs9QaUQ&s=19 people are getting angry...

lol

what is white nutella? <:Thonk:805904896879493180>

woah

how do i delete someone else's post?

Right click and choose *report* <:kekw:808717074305122316> <:BanHammer:805396864639565834>

Is a meme children never eated it and also Nutella doesn't sell it. But Lidl

A "German" supermarket

Lidl isn't even a supermarket

"eated" is wrong, "ate" is the past tense for eat

Never heard ate in my life from noone

It could be that you're wrong

https://www.reddit.com/r/Android/comments/z11ofm/add_to_android_support_of_jpeg_xl_3x_smaller_than/

if you never heard english irl that's a really low bar.

https://en.wiktionary.org/wiki/eat#English > **eat** (_third-person singular simple present_ **eats**, _present participle_ **eating**, _simple past_ **ate** _or (dialectal)_ **et** _or (obsolete)_ **eat**, _past participle_ **eaten** _or (dialectal)_ **etten**)

top comment: > Last time I checked, JPEG XL just isn't getting the same support compared to its rivals (e.g AVIF) I mean, that’s kind of the point of the feature request

Has someone used JPEG XL for Windows 7 screenshots?

https://twitter.com/DrQueuecumber/status/1596513077658517504

Surprising seeing Nvidia going all-out. I didn't think they were that big of a supporter.

Well this is just personal opinion of one person who happens to work at nvidia

lol, random people on the internet say funny things: > i already got .jpg_large forever ago is this just that but newer

(from https://www.tumblr.com/mffrueh/702331929159172096/koito-yuu-hello-tumblr-users-do-you-hate-webp)

It's Tumblr, what do you expect? <:KekDog:805390049033191445>

I hate webp

I don't

webp was rushed into the web before it was agreed that it would be an improvement over jpeg (it was not)

and now its another brick in the wall of web formats proliferation

webp lossless is cool tho ig

lossy webp is kinda useless tho

My 2cts: If Flash can be deprecated, why can't webp?

because flash requires a third party plugin

like java applets

I do think webp was better than *less optimized* jpeg, which was a frequent thing in the past and even today to some degrees

you can't reasonably expect that every jpeg is encoded with mozjpeg 😉

don't really see how that's relevant. Back then, many large websites and even more smaller ones required it even for basic things like site navigation. There are books on how to build websites in flash. It took seemingly forever for it to die but eventually it did drop out of browsers. If we start discouraging webp now we can have it gone in about 10 years (optimistic estimate).

But I'm going offtopic with this.

let's go to <#806898911091753051> , cause I think it's an interesting topic by its own

Yeah it's too bad that so much software is compiled with jpegturbo rather than mozjpeg

Even when the 3 milliseconds saved doesn't matter

In most cases quality is more important than throughput, unless you are encoding mjpeg video

https://twitter.com/GoogleOSS/status/1598406590117412879?t=8Vm0oVqSiV6BnbSAWwReAg&s=19

Google as a company is sending some mixed signals lately 🙂

not surprisingly `By Moritz Firsching, Junfeng He, and Zoltan Szabadka – Google Research` but interesting: <https://google.github.io/attention-center/>

there is not enough ecosystem interest, but Google keeps experimenting with JPEG XL? whut i mean, even if: (1) this research was conducted months ago and is only released now (quite likely), and (2) google open source isn't particularly important and/or connected to chromium team (even if technically they are connected, since chromium is open source) this is still really weird...

the answer here is simple: different teams 😉

right

thanks 😅

yeah, it's just individuals within google playing office politics

probably not even that

there's no evidence that the upper management cares or is even aware of the JPEG XL vs AVIF issue

yeah, would be good to have a wasm decoder in this demo as well (or maybe it doesn't support progressive yet?)

correct me if I'm wrong but wasn't the decision to axe JXL from chromium made unilaterally by a single random AVIF dude at Google?

unknown.

it can be said that the decision is confined within Chrome team, but otherwise not much is known publicly

is it possible to losslessly reorder the chunks of a progressive jxl?

to some extent, yes.

there is no single defined progressive method in JPEG XL and each image can differently split (and reorder) chunks, so you can't split or merge them freely, but you can reorder them freely

In principle you could get all the vardct coeffs and losslessly re-encode them in arbitrary order and with more or less passes

Currently we don't even use passes yet, just the minimum two (1:8 and then 1:1). The saliency guidance just changes the order in which the 1:1 pass is done (by applying a TOC permutation). Main advantage of this approach is that every pixel is only rendered at most twice, so the compute overhead is minimal (compared e.g. to libjpeg/mozjpeg progression which uses 10 passes or so)

https://www.theregister.com/2022/12/02/ml_attention_center_model_freed/

https://www.reddit.com/r/programming/comments/zas3pa/google_frees_nifty_ml_imagecompression_model_but/

i mean, im using jpeg turbo in my image viewer for the decoding speed, just with the assumption that mozjpeg would just be slower with decoding speed

not like i ever need to write a new jpeg with it lol

mozjpeg and turbojpeg are the same on the decode side

mozjpeg is specifically an encoder

i see

Are you sure about that?

I think you might be wrong.

Pretty sure mozjpeg has slightly better quality decoding as well.

Maybe it has different defaults, but I don't think the mozjpeg decoder is really different from the libjpeg-turbo one

Both have some options regarding which iDCT implementation to use and how to do chroma upsampling, so there could be a difference in defaults there

I doubt that the couple of milliseconds you save by using turbo, are worth not being able to see your image properly. Especially if you are encoding. Encoding only needs to be done one time, and if you do it badly, you will suffer the results forever.

It should be a federal crime to use turbo for encoding instead of mozjpeg

the primary advantage of turbojpeg over mozjpeg is for large servers that encode many jpegs from user-generated content

e.g. twitter saves a lot of server cpu cycles by using turbojpeg to encode pictures uploaded by their users

for an end user there isn't really any advantage, as the speed difference won't be noticeable

I report the chinese translation

https://zh-m-wikipedia-org.translate.goog/zh-cn/JPEG_XL?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=it&_x_tr_pto=wapp

Is translated from English

All the 63 citations

It doesn't include any of my Italians errors

Jon errors were corrected

But my italian was not strong enough so error remained

I plan to port this to English

With help of someone

And then translate to italian the new version

What the heeee are you doing. Why are you translating to chinese.

No it's David koung who did

I started drafting a response blog post to give some constructive feedback on the codec comparison the avif team did.

No idea how soon we'll be able to get it out, might take some time

You mean a couple of weeks.

I'm done writing the article, it's over 3k words and I think it will be a good contribution to the discussion. Still needs to be approved and prepared for publication, and it's weekend now so it will take some time. I hope it can get out next week though.

https://news.ycombinator.com/item?id=33933208 JPEG XL support has officially been removed from Chromium

https://www.phoronix.com/news/Chrome-Drops-JPEG-XL

https://www.reddit.com/r/programming/comments/zi66jj/google_chromechromium_goes_ahead_in_removing/

My blogpost "Contemplating Codec Comparisons" will likely get published later today or maybe tomorrow.

Sadly there is no discussion, seems only large media coverage could change this decisions - reaching journalists, influential people

I think my blog post will be the first one to comment on the AVIF team's codec comparison that was the basis for Chrome's decision. I hope there will be others commenting on it too.

We have to avoid getting cynical. I still assume that Chrome looked at the AVIF team's data and concluded that JXL is not worth keeping — which is not the right conclusion if you correctly interpret the data, but if you look at the data the way the AVIF team presented it, it's an easy mistake to make.

I doubt it. They didn't consult with the "JXL team" within Google about it, as far as I know, and I don't think they consulted with independent experts. I might be wrong of course.

has someone sent any feedback to their avif-feedback@googlegroups.com email?

Once my post is published, I will email them a link 🙂

I've seen a few people on Twitter say they emailed and have not gotten any reply.

It might take a couple of weeks to get a reply 😅

Personally, I don't think anything is going to "sway" them right now. It appeared political from the start. Even Mozilla has accused them of politics with other parts of the web, so it's not surprising. I think the best thing to do right now is keep working on it and retry in a year. Some of the people that are there now likely won't be and hopefully there will be fewer "yes-men" and others will start to provide actual constructive criticism from within.

> Anyone who's already tried the Output HDR feature in ACR 15.0 will have found themselves limited to JPEG XL as an output format, ironically just as Google announced it will be removing preliminary support for it from its Chrome Browser. However, v15.1 also adds support for Google's preferred AVIF format, which can only be good for compatibility. _via_ https://www.dpreview.com/articles/7584045384/adobe-demos-true-hdr-support-in-adobe-camera-raw-giving-a-glimpse-of-photography-s-bright-future

Good. Just support both. Now if only all software would just support both 🙂

https://youtu.be/Jyk87VVfh9s

My blogpost is scheduled to go live at 7 am US west coast time (4 pm European time).

that'd be <t:1671030000:f> (about 8 hours later)

Yes, I'm also deeply disappointed I will also have to wait until tomorrow the read the blog post 🙂

as a sneak preview: this is the conclusion: > The AVIF team provided a good starting point for doing a data-driven comparison of image formats that can help to clarify the desirability of adding new formats to the web platform. The compression results obtained by the AVIF team do confirm the results we obtained through subjective experiments and our own evaluations based on objective metrics. According to the subset1 results, the encoding speed of JPEG XL s6 is similar to that of AVIF s7 and at these settings, 9 out of the 13 metrics favor JPEG XL. Roughly speaking, at ‘web quality’, according to the best available metric, AVIF gives a compression gain of about 15% over mozjpeg (or more at the very low end of the quality spectrum), and JPEG XL gives a compression gain of about 15% over AVIF (except at the very low end of the quality spectrum). These are the results obtained by the AVIF team, and they do show the value of JPEG XL. > > In this contribution, I hope to have made some constructive suggestions on how to further improve the comparison methodology, and on how to interpret the results in the most meaningful way. Through constructive dialogue, we can together make progress on our shared goals: making the web faster, improving the user experience, and promoting royalty-free codecs!

(there are links in the above text to some of the plots like https://storage.googleapis.com/avif-comparison/images/subset1/rateplots/subset1_avif-jxl_t-1_avif-s7_jxl-s6_ssimulacra2__bpp-0.1-3.0.png but those got lost in the copy/paste)

another snippet from the blogpost: > In short, AVIF performs well at qualities that are too low to be useful in practice. Including these very-low-quality ranges skews the aggregate results in AVIF’s favor. A more useful comparison would focus on useful quality ranges.

Summary: AVIF (speaking on behalf of the Chromium team for reasons unknown), proved that JXL is a better format as it was being removed. <:kekw:808717074305122316>

This is comparison is at similar encoding speeds. I am curious how it would look like when defaults are used for each encoder (7 instead of 6 for libjxl and 6 instead of 7 for libavif+libaom). libjxl will be faster to encode but difference in compression probably smaller. Encoding speeds change over time as both encoders get improved. So diagram which is OK today could be obsolete in future after few new releases.

libjxl e7 is slower than e6, libaom s6 is slower than s7

and yes, things do keep evolving, both libjxl and libaom are still getting better/faster

(that plot is already obsolete now btw, the current git libjxl no longer has those discontinuities at ~0.55 bpp and at ~1 bpp, the current ssimulacra2 curve would look better)

we will never know what the full potential of any codec is — all we can do is look at the performance of encoders that are available. Both avif and jxl are very expressive bitstreams so there is likely significant room for encoder improvement in both. The jxl bitstream is more expressive/flexible than the avif/av1 one though, imo, and av1 encoders have been around for longer and have received more dev effort already than the one jxl encoder, so I think there's more room for future encoder improvements in jxl than in avif.

https://cloudinary.com/blog/contemplating-codec-comparisons

ooh it went live already!

so it wasn't released (my) tomorrow afterall 🙂

Was this still done with AVIF using 2 threads and JXL using 1? https://res.cloudinary.com/cloudinary-marketing/images/f_auto,q_auto/v1670951715/Jpegxl7/Jpegxl7-png?_i=AA

this was done by doing 100 image decodes and counting the total time, so it doesn't really matter how many threads the browser uses per image

it shows that decode speed itself is basically the same — but then it goes on to explain how streaming decode and progressive rendering do actually make a difference

there was also no mention that alpha was stripped for noto-emoji? https://discord.com/channels/794206087879852103/803574970180829194/1048280382128259142

even with alpha preserved it would not be a very relevant test set for lossy compression

on a second thought, I removed the link to HN, because it isn't on the front page yet and HN may have some kind of brigading protection

I think the blog post is very well argued. tbh anything is better than saying "we looked at the numbers and thought AVIF is better" and then weeks later dumping a bunch of numbers without any sort of analysis to go along with it

the only thing I don't understand is this table. maybe it's because of I'm not familiar with the correlation metrics? I'm gonna presume that closer to one means better but why are some of the numbers negative?

I followed the link in the article and my decode times on firefox (nightly 110.0a1 (2022-12-14) (64-bit)) are even more in favor of jpegxl (did the experiment more than once, numbers varies but orders of magnitude are the same)

`s.jpg: Decode speed: 161.42 MP/s | Fetch: 2.00ms | 100 decodes: 203.00ms s.jpg.jxl: Decode speed: 56.99 MP/s | Fetch: 2.00ms | 100 decodes: 575.00ms s.jxl: Decode speed: 33.30 MP/s | Fetch: 2.00ms | 100 decodes: 984.00ms s-fd1.jxl: Decode speed: 36.41 MP/s | Fetch: 2.00ms | 100 decodes: 900.00ms s-fd2.jxl: Decode speed: 37.19 MP/s | Fetch: 2.00ms | 100 decodes: 881.00ms s-fd3.jxl: Decode speed: 41.06 MP/s | Fetch: 2.00ms | 100 decodes: 798.00ms s8.avif: Decode speed: 26.32 MP/s | Fetch: 2.00ms | 100 decodes: 1245.00ms s10.avif: Decode speed: 23.80 MP/s | Fetch: 2.00ms | 100 decodes: 1377.00ms s12.avif: Decode speed: 21.54 MP/s | Fetch: 3.00ms | 100 decodes: 1521.00ms s2.webp: Decode speed: 71.70 MP/s | Fetch: 55.00ms | 100 decodes: 457.00ms`

yeah, I get the same thing, but then again the numbers are just lower for both jxl and avif on firefox than on chrome, which I think may be caused by firefox using older versions of libjxl and dav1d...

You can basically ignore the sign, higher absolute value means higher correlation with MOS so a "better" metric.

The sign is just because some metrics are "higher value is better" (like VMAF and SSIMULACRA 2) while other metrics are "higher value is worse" (like DSSIM and Butteraugli).

(the MOS scores we have are of the "higher value is better" type, so metrics that are also like that will get a positive sign)

Why does JPEG XL category on Cloudinary blog have a hyphen?

had to read this part twice too 😄 "absolute correlation" could have been less ambiguous

the table is sorting the metrics from worst to best, the exact numbers are just for statistic geeks and to show that it is not just my gut feeling that says PSNR and SSIM are no good, there's science that can be done here 🙂

does butteraugli 6-norm have a better correlation or not much different?

I'll report it 🙂

There is not that much difference, IIRC 2-norm had slightly better overall correlation on our data, but likely somewhat higher norms are slightly better at the higher end. Note that the 3-norm is actually already a mixture of 3, 6 and 12-norm, or something like that. Max-norm ("butteraugli" without qualifiers in the table) is too strict to be useful as a perceptual metric across a larger range of fidelities — it will punish the whole image for one bad pixel, which or may not be a semantically important one.

Refresh please 🙂

👍

I see, I thought maybe 6-norm would be more correct in something like Halls of fame/shame and because: https://discord.com/channels/794206087879852103/840831132009365514/900641563233906689

well maxnorm is basically inf-norm so I would expect 6-norm to be somewhere between 3-norm and maxnorm

It's hard for most people, including myself, to not get emotional about this decision. It's a very unfair one that was made unilaterally by our most exalted master at Google, despite the protests of both compression professionals and heavyweight market players. And this asinine decision will have far reaching consequences for everyone downstream of Blink/Chromium.

Our Exalted Lord at Google is asking us to get used to a web with no progressive loading of images anymore. And all existing JPEG must continue to take up the same amount of space.

This is the bleak future we must all embrace now. So saith the Lord.

And bringing up Firefox is essentially a punchline at this point. What with patches sitting ignored for years now.

Don't have enough manpower to click the merge button

for real.

It has nothing at all to do with manpower.

It's a choice.

I feel sorry for those people believing and spreading the "manpower" lie.

The web is open source lol, Firefox and Chrome are your only choices and they're totally open source lol!

under “Decoding vs Rendering Speed”, when it says “Schematically:” is that indeed just schematical or is it from actual measurements?

It's just schematical, but actual measurements do look like that (if you look in devtools, performance tab, with network throttling)

I don't know if there are plans to make dav1d do partial frame decoding, it should be possible in principle but it does complicate the api and implementation, and for video it is not really useful at all (unless you want to do ultra low latency video, I guess)

just finished going through the article, I found it very good and thorough, thank you for writing it

Thanks — I did my best to make it as constructive and clarifying as possible. It took me a while to understand how they arrived at the results/interpretations they arrived at, and I now think it's probably not a malicious comparison but just a bad interpretation of results, mostly caused by looking at bitrates that are relevant for video but not for still images (and BD rate giving additional focus on the low bitrates because metrics just have a bigger range of bad quality scores than their range of useful quality scores, and BD rate treats the metric score range uniformly).

That doesn't make sense. The majority of the numbers they averaged are from quality settings that are totally useless and produce unuseable output.

These are intelligent people (I assume!) so it's hard not to interpret that as malicious.

wb did his best lol

Things are always more obvious with hindsight, or when someone is explicitly explaining why something should be done another way. I can understand that they just took the full range of qualities they had in their test scripts (1 to 100 for jpeg, 1 to 63 for avif) and just took the average to aggregate encode speed. It's the simplest and most obvious thing to do. Same with BD rates: I think they just picked some bpp range without looking at images, and maybe assumed BD rate treats bitrates uniformly so if the range is a bit wrong, it's not a big deal, while it actually treats metric scores uniformly and starting the range too low kind of makes the numbers useless.

What they did wrong imo was not to involve other experts before making a decision, being too confident that they know how to evaluate stuff. But I don't think there was necessarily malicious intent. At least I hope there wasn't, and that they will actually be open to feedback, improving their data, and revisiting the decision based on better data.

Well, they claim they are open to feedback, just send them an email. Hmm, but you haven't gotten a response back from them yet...

Well, maybe we'll all be surprised still. Here's hoping.

Hmm, so they also ran the av1 encoding with --tune=ssim and then compared quality with ssim as if they are trying to artificially give avif an advantage there too...

I didn't realize that. Everything about their little comparison is over the top ridiculous and they obviously know what they're doing.

They're comparing codecs using a metric that their favorite encoder settings are specifically tuned for and acting like this is an objective comparison...

I have nothing against AV1 and I think it's a great video codec and it's just perplexing that some people seem like JXL is a competitor to or threatens it. JXL does not compete with AV1 and AV1 does not compete with JXL.

It's really bizarre what's happening to JXL in web browsers right now

Nobody was excited about webp or avif being fast-tracked into browsers, but people are genuinely for the first time excited about a new image format and "some guy" says no.

I wish I knew who my most exalted browserlord is so I can thank him for giving me the gift of The Web

you are acting as if they actually cared about their users instead of political patent/relevance wars

Making all the Most Wise decisions from the Most High

not much use of new codec if they can't weaponize it

Decreeing for all us mortal peons what image format we're allowed to use on His Web

what you gonna do? use other browser? bwahaha

all the right questions to ask, and do it loud. more people need to realize

No discussion, we ask how that decision was made and we get this lulzworthy comparison...

Just "some guy" said so and now it's all getting fast-tracked deleted

Not even phased out like what happens normally with other features

Behold, mortals. The open web!

Hark, lowly peons. Tremble and quail before Our open web standards!

tbf jxl's push feels too manufactured outrage tier for me too but gotta do something, i get, & kinda support anyway as the thing itself is legit nice from my own experiments

The planet kneels to Our whim.

this haven't quite been coverage for a while now btw

I just wanna be able to losslessly crush all these existing images

It's not manufactured. JXL was designed for the vast majority of how images are used on the web. AVIF was designed for low-bitrate... that nobody asked for. It has it's uses, but are limited. As an added bonus it works much better than PNG where WebP will sometimes be larger than PNG at lossess and will be a good storage format. Having real benefit is not manufactured. Hyping it up if it did as good as WebP would be manufactured.

i always kinda look too deep into these things. i'm just saddened that codec devs need to involve into social/political moves instead of just doing what they're best at and expecting adoptation. but yeah i still see discord server we're talking in as a bit of social chamber

and yes at this point it's not fair to call interest manifactured, even if it was bootstraped a bit artificially

thing is both legit in what it does and big entities already have signaled interest as well

its, just, idk, was there ever precedent of browsers adopting things from community input, instead of their own internal decision?

firefox seems to be adopting new things solely to not be left behind too much now, and chrome seems to be keen on pushing codecs that give them political leverage

https://www.reddit.com/r/firefox/comments/zlgsl3/chromium_ends_jpeg_xl_before_it_even_lived_3x/

So... you want Google to make their own decisions about what Chrome supports... but are against them pushing a format for political leverage... but JXL is using politics which you are against and would rather they remain silent about it so nobody will know about it and somehow magically get adopted? You're thought process is deeply confusing.

i don't want google to make their own decisions here, but it's been historical fact that they were making decisions like these on their own. it's not unexpected for me that they gonna resist solely for this reason

i wouldn't feel good as decisionmaker too if someone pushed my hand that much. and no, i didn't say that i want jxl politics to be silent either, didnt i say that i support this stuff too

its just idk way too contrived overthinking of literally everything that my head is and yes sometimes i get lost, its kinda hard

Remember that tune SSIM does not actually tune for SSIM. It is instead a different post RD modulation algorithm based on variance RDO, very roughly based on SSIM. It does not tune based on an actual SSIM metric.

They've been called out on it as well. I don't agree to listen to a single person requesting something, but having a large number of people requesting something and just ignoring them is not good for them. That's listening to your customers or potential customers. I just read an article the other day that they were worried about harming the company's reputation by pushing too much AI and I thought, "they're already doing that. No AI needed."

but it still gives better ssim scores, like x264 --tune ssim is just `--aq-mode 2 --no-psy`

I briefly translated and posted main points of this article to some Korean forum (sorta akin to HN): https://news.hada.io/topic?id=8029

I guess machine translation is enough to see if I've made a mistake or not, but I can write an English translation if you're curious 😉

And better visual results overall however.

yeah, though not intended for that and mostly for lower bitrates, due to not very good default psy modes setting (with proper psy tuning and probably aq strength, visual quality will be better, but still worse metric score) I personally use --tune ssim for streaming (because it is not a high bitrate, not the slowest encoding settings and impossible to tune for constantly changing content)

Basically as soon as I saw the comparison, I saw "AVIF has the fastest encoding speed of them all! Faster than even JPEG!" and I immediately thought, "wut?" The most often voiced complaint I hear from everyone is that AVIF is too slow! Then I looked at what they actually did, and saw they tested a whole bunch of different, weird settings that nobody would ever actually use in practice, and took the average of all of that, and I thought, oh that's weird, I wonder why they did it THAT way...

This was before I read anyone else's comments on "the data"

I'm not some sort of image coding professional and it's obvious at first glance this comparison is messed up.

Discord servers are always echo-chambers, it's designed like that. I would suggest adding IRC and matrix bridges, at least for one channel.

all chatting rooms are essentially echo chambers, not just Discord. if that's a concern you would want to have a publicly searchable and indexable forum instead.

Oops. What's the address?

I can't view any messages as a guest, I guess guest read access is disabled?

"on the fly" is not lowest quality, but fastest speed — which doesn't seem appealing to me since it isn't performing better than mozjpeg.

The Kodak set are scans of negatives I think, but still, quite different from how modern digital cameras work.

Other than those two nitpicks, it looks like a good summary! Thanks!

good point on the "on the fly", I kinda overlooked the fact that quality and speed do not necessarily correlate even for traditional encoders.

also... yeah, I completely forgot what Kodak meant :S

posted a correction comment, as this forum doesn't allow editing (for now)

ah thanks for explaining, this makes sense 👌

> Using the graph showing a >=~15% advantage of JXL over AVIF at relevant bpp ranges as the test image for the lossless comparison is shitposting on another level 😄 (from: https://www.reddit.com/r/jpegxl/comments/zls2aq/comment/j0ax9fi/?utm_source=share&utm_medium=web2x&context=3) haha yes I like this kind of little meta-jokes 🙂

heh marketing folks made that image while I was asleep — no way avif would look that blocky, it typically looks very smooth like shiny plastic 🙂

https://redd.it/zne1ys

It's crazy the divide there is for a situation that seems so straightforward.

a reasonable reaction when you grant AVIF as given (which is indeed one way to look at this situation)

there _were_ some common misconceptions that had to be frequently corrected, for example by an experimental flag chrome technically never guaranteed anything, so it's figuratively incorrect that "Google" "killed" "format support" (all three are incorrect to some extent)

chrome team's act becomes questionable only after considering AVIF and other experiments done by them, and we should be clear about this

I'm not sure how to even approach the top comment...

I don't understand how they'd think that: (1) AVIF is better than JPEG XL (2) Google did "nothing wrong" or "didn't take anything away"

JXL demolishes AVIF in features which says a lot when it can be smaller.

I'm not sure how to combat the idea that this is is just Google "[stopping] further commitment on an unreleased feature." AVIF and WebP were never as "ready" as JPEG XL was when they were added into stable Chromium, but because Google pushed them, it didn't matter. JPEG XL is as "ready" as can be. Those industry leaders mentioned were simply waiting from Chromium to roll it out so they could also get it ready. It's that chicken and egg problem again. Chromium won't add JPEG XL because it's just experimental, but it only remains experimental because Chromium refuses to add it.

Sometimes it feels like those commenters want the entire world to support JPEG XL before Chromium does. Do they want Photoshop import-export, OS-level decoding, and full JPEG XL support on Facebook, before Chromium even gives a chance at JPEG XL on Stable?

Looks like only large media coverage could reverse it now - write to journalists, youtubers, influential people describing this situation,emphasizing importance - that it is fight for future default image format: WebP-like or open JPEG successor

Chromium had the most mature first-class support for JXL including animations and progressive loading, basically on the same class as it's support for the GIF format or the classic JPEG format. And they just deleted it all, including everyone's contributions to getting the support up to that mature level.

only when a flag is enabled, let's not ignore that

Facebook and Adobe and others quickly chimed in on the tracking bug how excited they are to start using the new format as soon as Chrome stops putting it behind a flag.

It completely blindsighted everyone when all of a sudden Google announced it's getting removed. It's the exact opposite from what everyone expected.

Yes, they did take a lot away by deleting all that mature code

And they took a lot away from everyone who was expecting to begin using this format as soon as it was enabled by default. Such as Facebook.

Nobody expected this. It's totally random and nonsensical.

It would be like deleting all of the code related to HDR and saying that there isn't enough interest from the entire ecosystem for HDR support and there's no evidence that HDR is a big enough improvement.

By the way, speaking of that reddit post, I notice that for some reason the OP is getting downvoted to oblivion for seemingly no reason every time the OP makes a comment.

It's annoying that people have such strong feelings and feel the urge to pick a side and have a format war where there can be only one winner, VHS vs Betamax style. We can just have both avif and jxl and let everyone use whatever they like most.

I never saw it as some kind of competition between AVIF and JXL... until Google framed it that way.

It's the most random and unexpected thing in the world

The EXTREME amount of hypocrisy is infuriating too, for Google of all people to say "there isn't enough ecosystem interest nor enough improvement over existing formats" after they shoved webp down everyone's throats

The only way in which that statement can make sense is if "ecosystem" is defined very narrowly as "other browsers", i.e. Firefox and Safari don't support it.

Not that that was a blocker for webp or avif

Exactly, it's just mind boggling hypocrisy

You have no choice but to accept webp, and you have no choice but to fork your own Chromium if you want to use JXL.

It's their decision and theirs alone. Some mysterious and very exclusive club that decides what image formats everyone is forced to use or not to use. And they are far too important to talk to you or even reveal who they even are.

All we get is "WE have decided..."

"Maybe if leadership revisits this decision..."

Who ARE these people?

It's unfortunate that Chromium is used in so many different projects.

I don't care who they are, but I do care if there's any way to hold them accountable. With great power comes great responsibility, and it's a problem if there are no checks and balances in place.

It's very clearly not a democracy, which in principle is fair enough, this is after all a private company making decisions about a product they own, and that's how the world works.

But then we should stop pretending the web is an open platform, if it is essentially a Google owned platform.

That is where I was going too, yes.

If they are being so vague about who made the decision it doesn't sound like anyone plans on taking credit or being accountable or responsible when it comes to whatever effects the decision will have on Chromium and Google for example.

But really this is just speculation and who knows what the hell is going on here.

Google is a big company with many different factions and I have no idea who is responsible for what because it's not my job to know that.

It's just insane how whimsical and arbitrary this seems to be.

I don't know the internal structure of the Google Chrome organization but I think it is very large and as far as I understand, they do have a specific 'Codec team' within Chrome, which I think has the 'avif team' as a subteam. I think the leadership of the Chrome codec team makes decisions on that part of Chrome. I don't know if there are any 'appeal' procedures higher up in the Chrome department or in the Google company, but I don't think so.

comments like that reddit one seem to assume that the only valid comparison is with what Chrome previously was, rather than what it could have been

(paraphrasing) “chrome simply went from not supporting jxl to not supporting jxl” -> yes, and… that’s what people are complaining about. Can’t they?

can’t we hold chrome to a higher standard than “the previous version of chrome”?

Also: while behind a flag is indeed not the same as 'supported', and it did mean it couldn't be actually used at scale yet, at least people could opt-in to it and use it, which for some use cases is good enough (say using it on an intranet for internal sharing, where 'enable the flag' would be a minor inconvenience but not a dealbreaker). So even if you're just comparing M110 to M109, imo we will actually lose something.

Ugh I am still banned on r/webdev, I guess because 5 years ago or so I posted too many cloudinary blogposts there

https://www.reddit.com/r/webdev/comments/zne1ys/comment/j0k85hr/

Can someone ask for a pointer to that twitter thread? I don't remember anything like that and now I am very curious.

done

https://twitter.com/DemezProto/status/1605963877052604416?t=8bI3eJrIyHph2AStzwuAqA&s=19

lmao, was not expecting to see my drawing i did with some friends here

https://twitter.com/NinaoXyz/status/1606335073518845955?t=1WpfeI5wcTtwQnQOAWBG9A&s=19

We need to find a way to make it clearer that JPEG XL is not JPEG.

And also that the jpeg recompression feature does not mean that jxl is backwards compatible and can just be decoded by existing jpeg decoders.

There's a lot of (understandable) confusion around this, some people even apparently thinking Chrome is dropping JPEG support and things like that.

Perhaps using the term JXL would resolve that?

(I've seen such issues earlier, also related to version numbering - <https://twitter.com/tlively52/status/1517572876613808128>)

semantic versioning is extremely helpful if you are a developer of a project with 3rd party dependencies, but at the same time it's extremely confusing to normal people and not optimal from "marketing" standpoint

0.x in SemVer is extremely lax. So it doesn't matter as long as version is 0.x

There is a bit mismatch between the "microsoft" way of versioning, where 1.0 is basically the very first proof of concept alpha version and you can expect things to more or less start working at version 4.0 or 5.0, and the semantic versioning way of versioning, where 1.0 is a huge maturity milestone and ideally you never even need a 2.x since it's a sign that something was missed in the 1.x design.

Though I would argue that the "Microsoft" way of doing a major release whenever you need to make a breaking change is the right way, even if those changes are very minor and don't require most users to change.

Though this is why I prefer CalVer.

Semantic versioning does major version bumps when stuff breaks (at least after 0.x, where stuff breaks also at minor versions)

I think calver is okay for user-facing programs and services. For a library you depend on I prefer semver because it makes API breaks much more predictable

I guess my point is as soon as you have users you should be 1.0 (even if you didn't plan to be) as you already have that implicit API contract.

If applications use 0.x, they cannot assume that things will still work on 0.(x+1), but what difference does it make if we would have called libjxl 0.2 (the first one that was getting used, iirc) 1.0? We would still have wanted to make the api changes we made, so we would be at 5.0 or so now.

Yeah I would say the 0.x thing is more of a loophole, you are not SUPPOSED to stay at 0.x forever but some libraries choose to do so anyway so they are free to make breaking changes

https://0ver.org/

Not coverage but I bet if enough of us commented about JXL here we might be able to get Fireship to cover it. That would be a line of knowledge straight to the "general public" of developers. Especially web devs. https://www.youtube.com/watch?v=U_QNznf2FZA

how are things with JPEG XL and Chrome?

I don’t think anything changed. I am hopeful Chrome will come to adopt JPEG XL eventually, but it doesn’t seem like there has been any indication of change from Chrome’s part.

https://bugs.chromium.org/p/chromium/issues/detail?id=1178058

> Comment 365 by boihi...@gmail.com on Sun, Jan 1, 2023, 4:17 PM CST (a day ago) > .webp is annoying, please just stick with mp4, gif, jpg 🤦‍♂️

https://blog.codepen.io/2023/01/08/chris-corner-performance-talk/#jpeg-xl-we-hardly-knew-thee

https://youtu.be/oxKYkPyKCUQ?t=1455 WordPress full talk

not much new here, it's mostly existing stuff I wrote, translated to German: https://www.dev-insider.de/chrome-support-fuer-jpeg-xl-endet-wie-geht-es-weiter-a-6a91f68ab08c62190f0ec556ba8385c3/

🙉 LALALALA I INVENTED AVIF LALALALA

https://www.phoronix.com/news/Mozilla-Neutral-On-JPEG-XL

> So we don't see support for JPEG-XL as either good or bad for the Web. We might find it necessary to support the format if usage becomes **more widespread,** but that will be a product decision[1]. wait what do they mean by jxl not being widespread?

not sure but it could be codeword for something like "we won't support this unless chrome decides to"

a few of those comments on that article hurt me to read, I would reply to a few of the people on there but I dislike making accounts for things and also my grammar and typing style are awful

That's a rather bad translation indeed. Mozilla did not say who they consulted, for all we know they only consulted themselves.

Lol -- the latest from Phoronix forums: " The author of JPEG-XL, Jon Sneyers has a habit of writing horrifically slow compression algorithms, just like he did with FLIF. "

I am not "the author of JPEG-XL". I'm one of the main contributors, but large parts of jxl (e.g. most of vardct) were created by others.

It is true that the part I'm most responsible for (modular) can also be horribly slow (try e10 lossless encoding).

But I'd say we spent quite a lot of effort to make jxl faster than flif, or at least to have ways to use it in a very fast way while still being effective in terms of compression (though of course slower will always give better compression)

Lossless e1-e3 are quite nice now (though e1 is mostly Luca Versari's work and e3 is mostly Alexander Ratushnyak's work)

It seems jpeg xl will be everywhere except browsers <:Google:806629068803932281>

We'll see what the future brings. Clearly browsers will not be the early adopters they used to be in the past: for webp and avif, browser support was there (at least in chrome) well before the formats were used or even supported in non-browser use cases. I am still assuming that browsers will be late adopters.

I know I don’t often post here, but I’m frequently lurking. I wanted to say: I’m glad y’all seem to still be hopeful and convicted about JPEG XL. From what I am able to see, it is a beautiful format, and I’m glad whoever is involved with it in any way seem to be proud of it!

web.dev released a new series of articles about images <https://web.dev/learn/images/> jxl got... a mention

Should say "major browser" instead of "browser" imo

I think there are now 5 browsers supporting jxl, all are firefox forks: - Pale Moon - Basilisk - Waterfox - LibreWolf - Pulse Browser

I think librewolf's and pulse's support are incomplete

librewolf just has the basic support that is present in firefox nightly while with pulse it's either the same situation or their support might flat out be broken because i'm not sure if they removed the nightly check

and in the case of librewolf I don't think the support is even turned on by default

Thorium (https://github.com/Alex313031/Thorium/) is still on M109 and has jxl enabled by default

It's good to learn this lesson as early as possible: Do not react to something that is beneath deserving of your attention.

some of the comments seem like bait or something of the sort however others seem to be from people who just have false information or a misunderstanding of something

Yeah lol. You're possibly the most outspoken developer working on JXL and the author of FLIF/FUIF... but ultimately the JXL codebase was forked from the Google libpik codebase and not your (much smaller and lighter) FUIF library

But it's understandable why people first hearing about JXL think YOU are the author lol

The other developers are relatively speaking more low profile

They're just ignorant.

https://www.golem.de/news/jpeg-xl-die-browserhersteller-sagen-nein-zum-bildformat-2302-171653.html

if there would be unquestionably neutral image benchmark signed e.g. by JPEG, Adobe, independent experts, etc. (not only individual benchmarks), each such article would mention it, discussing results ...

sure it never will be perfect, but should be built as neutral and objective as possible, trying to gather various experts e.g. JPEG, MPEG, AOM, Adobe, Affinity, etc. ... to avoid problematic situations like now of everybody relying on own benchmarks ... to direct development of future codes

https://nikolin.eu/tech/a-closer-look-at-the-rejection-of-jpeg-xl-by-chrome-and-firefox/

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

This looks like it was written by AI.

it really does

https://www.sir-apfelot.de/jpeg-xl-48183/

https://www.youtube.com/watch?v=YrClf3I7AaM interesting about JPEG

https://youtu.be/z0Q3bAL-wXw

the image on the jpeg.org/jpegxl website has been updated so you can now use it as a (subtle) browser support test

Thorium on the left, Chrome on the right

(note the text overlay in the bottom right corner of the image)

lol nice

funny way to use official infopage as advertisement

nice

Also: the white paper has been updated! https://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf

https://www.sir-apfelot.de/en/jpegxl-48183/

https://motionmill.com/2023/02/google-stopt-jpex-xl-gebruiken/ Nice article summarizing the browser support situation (in Dutch though)