JPEG XL

Not facebook

I added link to pdf

https://ru.m.wikipedia.org/wiki/JPEG_XL

It seems ru is the standard

French had a 8900+ commit on february 2021 but is very bad

But Russian isnt the original they uploaded in february 2022

Is there an ukraine wiki of JPEG XL?

Wikipedia?

.

What is missing a subtitle of how butteraugli works

But is too early

https://it.m.wikipedia.org/w/index.php?title=JPEG_XL&action=info

All the info about the page

Number of views etc

added some info about windows 1 1

https://it.wikipedia.org/w/index.php?title=JPEG_XL&diff=prev&oldid=127885968

though i'm on windows seven

so if you have windows eleven

click this https://discord.com/channels/794206087879852103/822105409312653333/985981633016508427

and tell me if i'm correct

do not edit anything

that's the commit when i did most changes

https://it.wikipedia.org/w/index.php?title=JPEG_XL&diff=prev&oldid=124581673

here's all the changes

font olympic sans

better than vazirmatn pt9 for reading in my opinion

it seems only on mobile chromium

bug

what means your article is in watchlist

like the jpeg xl article in italian had only 4 users in watchlist

now 30 and this in a day

does some dev have fear of my contribute

https://en.wikipedia.org/wiki/Help:Watchlist

Se il numero di osservatori è minore di 30, per motivi di privacy e sicurezza questo non verrà mostrato.

If the number of observers is less than 30, this will not be shown for privacy and security reasons.

<@794205442175402004>

https://it.m.wikipedia.org/wiki/JPEG_XL

Finally i fixed all the formattation

Wikipedia It official

17:52 15 june 2022

Update: I watched a lot of rules of other codec pages

Maybe i will try contritubing to aomedia pages

https://groups.google.com/g/linux.debian.bugs.dist/c/HLZXKj1NLIE?pli=1

https://www.phoronix.com/scan.php?page=news_item&px=GIMP-2.10.32-Released

repost

https://it.wikipedia.org/wiki/JPEG_XL

i caused errors

"First Beta Krita 5.1.0". https://krita.org. 2022-06-14. {{cite web}}: Cite has empty unknown parameter: |1= (help); External link in |website= (help); Unknown parameter |access date= ignored (|access-date= suggested) (help)

that all i caused for doing thing i dont even readed how to do

i could have a ban

maybe someone of you will do

https://it.m.wikipedia.org/wiki/AOMedia_Video_1

https://it.m.wikipedia.org/wiki/JPEG_XL

Updated file formats pages with fixes

another big fix

https://twitter.com/atomicthumbs/status/1545228274237730816?t=VMntxel4EUnPRoDouRr81Q&s=19

Do they realize that Google also has their hands in JXL? <:kekw:808717074305122316> Also, lossless WebP is quite good :)

https://boards.4channel.org/g/thread/87703196

who are these people that use that kind of language to discuss image formats?

> FLIF died for our sins and became FUIF and then JPEG XL this made me chuckle though

language is a social construct

strong salty baits on that thread

Some jxl mentions here: https://www.computerweekly.com/blog/Inspect-a-Gadget/Circular-IT-series-Cloudinary-Small-changes-to-cut-bandwidth-lead-to-big-CO2-savings

Surprised it didn't go over responsive loading - JXL can store multiple sizes that progressively get downloaded and displayed as needed (a thumbnail may only need the first few dozen KB). Other formats need additional images to be encoded and managed to do the same. This feature combined with the upcoming container queries and container units will likely add to that bandwidth saving.

Yes, though for that to work, browsers and possibly http need to be updated to facilitate effective responsive loading (without adding extra burden to web devs or having to update hosting/cdns too much)

Couldn't ranges be used? https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests Also, browsers haven't even implemented it yet, so that should be part of adding it.

Ranges could be used if you make some assumptions like "first 1kb should be enough to get the TOC"

For the vast majority of images, that's likely to be the case. Only where someone dumps a novel's length of comment is it likely to exceed that, in that case it will have to keep downloading portions until it gets the entire header.

https://www.phoronix.com/scan.php?page=article&item=rembrandt-windows-linux&num=3

JXL encoding & decoding are now a metric for Windows vs Linux 👀

Browsers already do something similar for video, where they need to load enough to get metadata and a preview image, but not the entire video itself

Edge (so Chromium) at least just requests the entire file length, then stops the request when it's got enough

Doing that with JXL would let browsers know the exact file offset to stop at, and then if it's ever needed at a larger size it already knows the new ranges it needs to request

That's incorrect, it won't start showing or requesting anything from the video until it's actually played. There is a `poster` attribute for videos that developers can set that points to a preview image/thumbnail of the video that will load prior to the video loading. Prior to the poster attribute, developers would use css and/or javascript to display an image before the video played. https://stackoverflow.com/a/20076039/1456201 If Edge is preloading videos then they've likely gone off on their own and are doing something they probably shouldn't.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/video#attr-preload

If you don't supply a poster, the browser takes the first video frame as part of the metadata

Ideally of course the author would supply the size and poster image up front, but not everybody does that (Same as for normal images)

I'd never heard of this. Looking around it looks like a number of people just found out about it in the past year. This seems very questionable - I don't think the browser should be doing this for videos. I don't see any way to disable this functionality either. <:Hsss:806131225278152756>

TBF, displaying the first frame is probably a better idea than just displaying black.

`preload="none"` should entirely disable it and you'll just get a default sized (300x150 iirc) blank square, unless of course the author supplies width/height and a poster image

That should be up to the user. Using `preload` puts the action in the hands of the developer.

I think the worst one is "auto" actually, doesn't suggest that it could load the entire video file without user intervention

Just loading a preview frame at least will only ever download just enough to decode the first frame, not much worse than a image

It's also just odd to have it as a tri-state flag, and include an "auto" value that isn't the recommended default

I think that's fine to let the developer decide how to do such things as it will be necessary for things like short looping videos (like memes or icons), but give the user the ability to say no. Add a flag in chrome, config entry in firefox, etc that allows the user to disable video preloading.

Especially on mobile I wish there was more control over when what gets (pre)loaded. Sometimes data can be _very_ expensive, and then I don't want to waste it all on some funny cat video that happens to be on my twitter timeline

(another issue is that any new browser configuration options won't help when you're navigating through native apps like twitter, facebook, newspaper apps etc)

I recently was in an area with only 2G reception. Basically the web has become totally unusable at that speed. Even just doing a google search (which should be just a few kb of text as a result) doesn't work at all anymore on 2G, probably because of all the tracking javascript stuff

Not sure if it still does it, but I know Safari on iOS was like that, overrode the page to never preload anything until you pressed play, worked pretty well

Google worked with IAB years ago to come up with guidelines for acceptable advertising on websites and added a ranking factor which should reduce rank of sites with a lot of annoying and disruptive ads... a number Google's own properties don't follow the guidelines and sites that have 4/5/6 highly disruptive pop-over ads will still show on the first page. Same with performance, they basically set the standard for website performance and they constantly advocate for it's use, but many of their own properties don't follow it.

"Do as I say, not as I do"

It looks like i'm blocked from editing the Wikipedia spanish jpeg xl article

And also flagged

But there is an error

GitHub and not Github

If you are spanish please fix it

Now

Anyway i think those things i wrote will be one day rewrote from scratch from neurotypicals

And they will delete my knowledge

what i did that is considered so bad

i have english article in av1 wikipedia italian

and no flag

nobody has reported it

yes i know that is done by a bot

but i don't understand the spanish hate against me

Probably translation is wrong and incomplete

Wikipedia generally considers, so to say, an article hoarding (arising from a far-above-average level of activity on a small number of articles) as a bad signal because of the past experience with trolls and bots. it's a good idea to refrain from editing from time to time for this reason.

But why italian Wikipedia accept English links and on spanish all got flagged

I have like 30 English links on italian

Do you have the docimentation for spamizh

different Wikipedias have different thresholds, and that many links can be seen as an advertisement

So italian is an exception

There many many wikipedias that disallow English links

I don't know, maybe administrators understood they are not advertising, maybe not

And if i don't know the rules of a Wikipedia i should refrain.

refrain from being too attached on a single article, I meant

as I've mentioned this is not necessarily bad but is a bad signal

And editing a Wikipedia and adding English links if i don't know the rules

Like i go to Wikipedia french and add English links

But i don't know nothing of their rules

if you can explain that those links are necessary for the completeness of the article and there are no substitutes for the native language, you should be fine

Of what they allow

but there is no guarantee that administrators can understand that *without your explanation*

https://es.m.wikipedia.org/wiki/JPEG_XL

Do you want to fix yourself

GitHub

I know no Spanish, sorry

And not github

Who knows spanish here

I have fear they delete my things

That's why i tend to fix all i have from other wikipedias

<@263309374775230465> why ydntou fix spelling

uh, so you don't know Spanish either? that can be quite problematic...

No im italian

But i translated myself

So if i can fix even the spanish

GitHub should be written GitHub

That's wrong. Write only Italian articles.

partial translation is worse than no translation, unfortunately

Do you have a Wikipedia account?

Yes

So you don't know spanish so you won't do

And why

What is the risk

I have no certification

And im autism

Wikipedia could block all my accounts

You should not write articles using machine translation.

if you know your article works in Italian, stick to that

Is for every Wikipedia this rule valid?

many rules are local to each Wikipedia, that's whether you know the language or not can be a deciding factor (because otherwise how would you know the actual rules for each language edition?)

So i'm autistic which languages i should edit

Ah, is necessary

your native language?

That was my question

And why

I want to fix spellings

I can't

I think this is quickly becoming an off-topic so let's go to <#806898911091753051> from now on

ok we talked here 40 minutes

https://discord.com/channels/794206087879852103/806898911091753051/1000777880395055135

still 3 doubts

but nothing

posted 2 links

one in offtopic and one in other codecs

3 images

this was the start of jpeg xl article hidden user

https://it.wikipedia.org/w/index.php?title=JPEG_XL&oldid=119327557

phoronix likes JPEG XL in FFmpeg 5.1

https://www.phoronix.com/news/FFmpeg-5.1-Released

updated also the italian and spanish

spanish i'm not blocked anymore

even if i'm not proficient in the language

i also edited github to GitHub

ENGLISH SPANISH AND ITALIAN HAVE ALL THE SAME INFORMATION IN THE STANDARDAZIATION

https://9to5linux.com/krita-5-1-released-with-jpeg-xl-support-full-webp-support-psd-improvements-and-more

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1341218-krita-5-1-released-with-jpeg-xl-support-xsimd-for-better-paint-performance

Is there a way to get a translation of that? I am curious what they did but I cannot make any sense out of Japanese...

So are they experimenting with a new MA tree learning method then? <@179701849576833024> this could be interesting...

ehhhh that doesn't seem like a new MA tree learning algo

I do have ideas on that, but I doubt I'll have time to try them out anytime soon

https://youtu.be/FIG3I8Sp2qQ

https://chromestatus.com/feature/5188299478007808 got an update

though on the site it shows less info than email diffs

what does the e-mail diff show?

mostly the same but with some extra stuff like ``` web_dev_views_notes: old: new: industry support such as Intel and Adobe are listed in the tracking bug ``` which isn't visible on the page for some reason

at least industry support is recognized

another thing too is that the first link under "Demos and samples" is half dead

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

https://krita.org/en/item/intel-becomes-first-krita-development-fund-corporate-gold-patron/

"We are also excited about the support for JPEG XL, offering significantly better HDR experience and higher compression ratios, hereby meeting the needs of image delivery on the web and professional photography."

https://news.ycombinator.com/item?id=32970037 libjxl 0.7.0 made into the HN front page.

in my experience, that's possible with a good timing and a good amount of initial push (which can be as low as 10 points)

and then depending on the topic it can stay far longer

JPEG XL is recognized

I amplied the wiki page for es and it

Italian Is already fixed

En has received an important commit

Despite duplicate referiences

With veikko I have talked in his wiki Discussion about jxl

He's Active in AOMedia av1 article

He fixed many things

I also created a script from the xso page to track my wiki Activity

Of all global webpage

I added some text

Improvements over fuif wasn't there

Usually Wikipedia English is filtered that means don't want information to spread in other Wikipedias

Like Arab wikipedia

Etc

At least they need their wikidata code their bibliography

They don't just wanna accept everything

Because it can spread in french or japanese Wikipedia

Or in other big sites I don't know

Italian Wikipedia is a small community so couldn't care less if arabs steal their contents

🤔

https://note.com/leftbank/n/n894c317cb7ef

Spanish and french Wikipedia updated with latest avif version

Fixed

Now is 0.7.0

I didn't counted the base versions

Is useless on Wikipedia

https://helpx.adobe.com/camera-raw/using/hdr-output.html

https://gregbenzphotography.com/hdr/

https://youtu.be/ZpSQYs3YaGI

https://www.abyssmedia.com/heic-converter/avif-heic-jpegxl.shtml

I did

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

Yeah that's why I created it 🙂

https://tenor.com/view/nice-one-good-job-friends-joey-gif-15193666

Vote Booster: Vote now for a 10% boost. <https://arcane.bot/vote>

this really worries me and I don't want to accept that this is happening however I believe that this is most likely google's final decision based on the timing and how I was already sort of worried of this as a possibility. sadly it looks like jpegxl is gonna be forever relegated to professional use only and never reach general usage

so much for progressive images and smaller already existing jpegs on the web 😢

We will see, I don't think long-term conclusions can be made right now but the Chrome team is not really on a good track to promote royalty-free codecs for the web, enabling hevc and then deprecating/delaying jxl

it looks like somewhere at google multiple people decided that jpegxl will be deprecated what is going to make them revert this decision?

hasn't this happened before? i thought they just tend to deprecate things after being behind a flag for a few versions in a row unless they explicitly extend the deadline

and they have extended that for jxl in the past

This is the first time they add an explicit note saying it will be removed though

But yes, so far they have not made any official announcement of a decision let alone a decision rationale, so I am curious how they will explain this.

Av1 codec is superfast in intra

Plus it can now compress 30% more overrall at cpu 8 mode good crf 26 bit depth 10

Aomenc

Some blocks are overlap

But do you think users will notice or care?

I have no clue what you mean by that but this does not seem to be the right channel for it.

I used latest ffmpeg from svt on FastFlix

Show proof

if you want that quality ecm 6.0 wins

https://discord.com/channels/794206087879852103/803950138795622455/1036290523935281162

low bitrate and fast speed is superior to av1

with a proper implementation it could be good

i can't show obviously my personal videos

and the thread is about photos

nobody wants ssimulacra 40 cjxl e6 q 52 photos

modular will always be a lot lower, like if you use q 88.3, modular will be max 63.4

is how jxl works

i don't know if video codecs are the same

ecm 2.0 seems even too experimental

https://www.theregister.com/2022/10/31/jpeg_xl_axed_chrome/

https://www.phoronix.com/news/Chrome-Dropping-JPEG-XL-Reasons second article on phoronix

Lol "The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default"

it's unfortunate that jxl doesn't do very well at very low quality and since google created 'core web vitals' that penalises sites for using high quality/high bpp images, I wouldn't be surprised if their real reasoning is that choosing avif and avif only may make websites faster time and time again I get annoyed at new formats and the people using those formats for doing things along the lines of "same quality, lower bpp", instead of "better quality, same bpp" . . . just my thoughts

It's just such a disrespectful comment to make. It's cruel to dismiss years of your colleagues' work by calling it insufficient and little else. Have any Googlers here received clarity on this?

> web developers aren't aggressively pushing JPEG-XL Huh?

The deprecation be getting internal coverage at Google & Microsoft w/the API owners: https://twitter.com/slightlylate/status/1587030785197953024

Not surprised, I've heard a lot of cases like this. The different departments within Google rarely talk to each other.

An origin trial would be perfect. All those companies that have made comments (e.g. facebook, shopify, theguardian) would be able to use it and provide a ton of useful data

if anyone is unfamiliar with those, an origin trial (in the tweet: OT) for chrome is where you put a meta tag in your html which enables a feature flag (in this case, it would enable jxl).

Cloudinary was ready to start an OT but Chrome didn't allow it for reasons unclear. We are still very eager to do an OT if they let us.

(we would need a domain-based or response header based OT though, not a meta tag based one, since we don't control the html of our customers, only the images)

yeah might be difficult for CDNs, as the request needs to send `accept: image/jxl` right? sounds like a bit of effort would need to be made to accommodate..

Yeah but doable, either they change the Accept headers when making requests to OT domains, or we send jxl plus some marker in the response headers when we get a UA that we know will handle it.

The issue with that is what was posed above: That would likely be done by the API team but they knew nothing about it...

the latter sounds like a better solution 🙂 check UA for compat, set `Origin-Trial: TOKEN_GOES_HERE` response http header and you should be golden I hope they don't just say no to an OT and not elaborate..

I don't recall exactly how it went but I remember proposing it in the summer of 2021 but it somehow never happened

imagine if edge maintains support without chromium 👀

Edge doesn't even have AVIF support yet. I thought the AV1 plugin would work but apparently not. Would likely be looking at years before they implemented it.

https://tweakers.net/nieuws/202908/google-stopt-na-enkele-maanden-al-met-ondersteuning-voor-jpeg-xl-in-chromium.html (in Dutch)

Frikandellen language™️

German report on the matter https://www.heise.de/news/Beerdigt-Google-so-JPEG-XL-Chromium-entfernt-das-Grafikformat-noch-vorm-Start-7325682.html

https://technewsspace.com/chrome-no-longer-supports-jpeg-xl-images/

https://www.techzine.nl/nieuws/applications/507409/google-stopt-na-enkele-maanden-ondersteuning-jpeg-xl-in-chromium/

http://blog.fefe.de/?ts=9d9fe377

<:FeelsReadingMan:808827102278451241>

All wrong what he said

https://www.reddit.com/r/technology/comments/ygtq5z/google_chrome_is_already_preparing_to_deprecate/

It's great to see that other people are suspecting suspicious, possible conflict of interest activity going on at Google as well.

https://www.cnet.com/tech/computing/chrome-banishes-photo-format-that-could-save-space-on-your-phone/

Wow, didn't expect CNET to pick it up. That's probably the largest publication so far.

> And AVIF lacks a "progressive" option that quickly gets a low-quality image onto a website then fleshes out its detail. That helps websites load without elements jumping around. Web.dev REALLY needs to remove that false advertising.

> That helps websites load without elements jumping around. Technically you can fix that by adding the `height` and `width` attributes, so that's not entirely true.

Until it waterfalls and the initial image data comes in it'll still be a 0x0 element. It won't jump less, just faster.

i could never be a web dev. not sure how you all remember all these edge cases and rules 😛

https://www.techzine.eu/news/applications/93077/google-ends-support-for-jpeg-xl-in-chromium/

Until it waterfalls and the initial

New ones pop up all the time. Also, they complain about there being too many image formats. Ten years ago there was BMP, GIF, PNG, JPG, and APNG. Those would get replaced with WebP, AVIF, and JXL. So... not sure how fewer formats equals more? Also, there nearly 100 different APIs and growing every year: https://developer.mozilla.org/en-US/docs/Web/API

Stephen was asking me some questions on twitter yesterday so I suspected something was coming 🙂

Nice article on cnet!

Yup, that's a very good read!

You know, I just realized the huge advantage that ssimulacra2 and butteraugli as metrics give us. It allows us to show numbers that PSNR and SSIM metric people can actually understand 🙂

It's still not recommended to blindly trust any objective metric, but yeah

Getting ready to get a reaction blog post published on the Cloudinary blog.

Of course, but metrics allow coding gains to be easily measured and quantified over a whole frame. Very nice to see gains in ways that my eyes don't reliably see, even on a high end screen in demanding conditions.

Yes, metrics are hugely useful, and better metrics more than bad metrics.

they can help to know where to look, as well

“hm? butteraugli doesn’t like the result on this image? let’s look at the heatmap”

“oh, yeah, that’s bad”

Anyway, thank you for the scripts you gave me yesterday. They are quite useful 😄

You're welcome. I should probably clean them up a bit and put it on github

My post on the Cloudinary blog should go live soon. I never wrote a blog post this quickly before — started writing yesterday, copy editor went over it when the US woke up today, final tweaks were made just now, it should go live soon now.

I hope it won't seem too rushed

https://cloudinary.com/blog/the-case-for-jpeg-xl

It's live

Nice write-up!

the list of benefits in the conclusion makes me want to formulate them in the style in which Rust advantages are often listed (zero-cost abstractions, fearless concurrency, efficient C bindings, etc. https://www.reddit.com/r/rust/comments/8k8sr4/what_is_your_favorite_rust_feature_zerocost/)

- Fearless progression - Efficient JPEG bindings

i hate that i recognize your username ||from pcj||

i knew it seemed familiar but it took reading "- Fearless ... - Efficient" before i knew

I emailed HN and they unbanned cloudinary: > Someone was overpromoting it and got the site classified as spam. That was > years ago, so I guess we can unban the site now. > > As for https://cloudinary.com/blog/the-case-for-jpeg-xl, I've unkilled the > first submission of that article ( > https://news.ycombinator.com/item?id=33442281) and put it in the > second-chance pool (https://news.ycombinator.com/pool, explained at > https://news.ycombinator.com/item?id=26998308), so it will get a random > placement on HN's front page. > > Let us know if you have any questions, > Daniel (dang)

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

Does seem to get upvoted, thanks <@826169751821615114> !

Mozilla has restricted comments on the jxl's bug https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c61

> I didn't care so much about JPEG XL, now thanks to Google derping I want it everywhere

<:kekw:808717074305122316>

I'm surprised Chrome hasn't locked their bug yet.

Heise/iX journalist has been asking me questions so we can expect an article in the German tech press too.

https://www.heise.de/news/Drei-Fragen-und-Antworten-Google-schiesst-JPEG-XL-ab-und-das-voellig-zu-unrecht-7329110.html

I love how the computery things are untranslated

Jon do you speak german or is this a translation?

I do speak a bit of German but it is a translation from English

ah

My German is not good enough

do you have and/or are allowed to share the original transcript? I don't speak German so I can't read the article

I figure that's better than a translation into German and then machine translated back into English

Uh, sure, one sec

1. Let's start with the elephant in the room: WebP. Google has been pushing an own format for a while now – which is Web-focused and video-derived. JPEG XL is none of those things, but did Google nevertheless kill off a competitor? Both WebP and AVIF are video-derived web-focused image formats that are being pushed by the Google Chrome codec team. Ironically, a different Google team (part of Google Research in Zurich) is involved in JPEG XL. It is organizationally far away from Chrome though. JPEG XL is not a competitor to the video codecs from which WebP and AVIF were derived (VP8 and AV1). It is not a video codec at all. Nevertheless, the Chrome codec team seems to want to push not just the video codecs they are developing, but also the image formats that were derived from them. I think they fear that if JPEG XL gets traction, WebP and AVIF adoption will suffer (and that fear is probably grounded), exactly because of the overall technical superiority of JPEG XL.

Then again, I do think these formats can also "coexist peacefully", as they are quite complementary: AVIF is great as a GIF replacement and for use cases where fidelity is less important, while JPEG XL is great for high-fidelity still images.

2. Google claims, there isn't enough interest in JPEG XL. Several huge tech companies disagreed – Facebook, Adobe and Intel aren't exactly lightweights. But do those companies have the power, to make JPEG XL a success after the Chromium-setback? Chrome is a very important factor: effectively the Chrome codec team has the power to decide what codecs are supported on the web platform in general (it matters little what other browsers do, considering Chrome's market share). So their decisions do have a huge impact, for better or worse. It is a somewhat scary thought that so much power is concentrated in a single company. Only time will tell how successful JPEG XL will be. I think that even if Chrome remains stubborn, the technical strengths of JPEG XL are significant enough for the format to get traction outside the web, which could eventually lead to Chrome being forced to reconsider their decision.

3. One of the harder to quantify accusations by Google was, that JPEG XL does not have enough advantages over existing formats. Looking at the data, that's obviously not true on a technical level. How would regular users and developers see those benefits? I think the biggest benefit is that JPEG XL brings improvements in both image fidelity and compression, while the existing formats (being video-derived) have focused on improving compression at the expense of fidelity. In recent years we have seen many improvements in the fidelity of capture and display technologies — cameras are getting better and better, HDR and wide gamut displays became mainstream — but end users will not be able to enjoy this improved fidelity without an image format that is actually designed for fidelity. Also, JPEG XL gets excellent performance at reasonable speeds, while a format like AVIF takes a minute to save one image (if you want to get good compression; faster AVIF encoding is possible but then its compression performance is worse). For use cases like Netflix movie posters, which are encoded once and viewed millions of times, encode speed may not be a very important consideration. But for regular users, it most definitely makes a difference. Finally JPEG XL makes it possible to instantly reduce the storage size of existing collections of JPEG images by about 20% without any risk whatsoever. This feature is unique to JPEG XL, and makes it a format that not only looks at the future, but also respects the past and offers a great transition path.

For those who have not seen it, Jon's blogpost was linked on Reddit: https://old.reddit.com/r/programming/comments/ykq4fr/the_case_for_jpeg_xl

They put my article at the top as 'featured blog post': https://cloudinary.com/blog/

https://www.thehindubusinessline.com/info-tech/google-chrome-removes-jpeg-xl-image-support/article66094598.ece

> The tech giant said in a statement, “During our experiment to support JPEG-XL in Chrome, we concluded that it did not provide substantial benefits over AVIF, and unlike AVIF, JPEG-XL has not been adopted by other browsers. We do not plan to support JPEG-XL at this time and will instead continue to focus our efforts on improving existing formats in Chrome.”

This is a slightly different statement than what they originally put in the bugtracker: now besides the "not sufficient benefits" point, the point "has not been adopted by other browsers" was added, and also the decision itself is toned down a bit: they went from "we will be removing the JPEG XL code and flag" to "we do not plan to support JPEG XL at this time".

Correct what? Could very well be that actually contacted Google and got that reaction.

Not as Nvidia in general, but, from some scientists <https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c175> ```I am a scientist at NVIDIA researching image and video compression. I do not speak for my company but in my personal capacity as a leader in this "ecosystem" (as you've put it) I strongly disagree with the decision to cut JPEG-XL. I'm not sure how your gauged people's interest but based on the comments from other top people in the compression field in this bug report you may consider reevaluating your criteria.```

Right, Stephen told me that he added a reaction from Google.

but, actually, jpeg xl was already in all popular browsers, just not enabled by default and also from a certain period firefox for some reason suddenly halted all decoder updates <:WTF:805391680538148936>

<@239702523559018497> you did the initial firefox support of jxl, right? Do you know what is going on in firefox?

To me it looks like Chrome says they don't support jxl because Firefox doesn't, and Firefox doesn't support jxl because Chrome doesn't.

https://hydraulic.software/blog/6-why-desktop-apps-matter.html

tfw desktop apps are just chrome bundled in a desktop app

The article does make some valid points imo

> If HTML has become so fat that even something as basic as better image formats has become impossible, what’s the alternative?

That's the kind of existential questions a browser dev should expect if they're citing "maintenance burden" as a reason why we cannot have nice things.

Going forward, new formats are likely going to require a wasm implementation. Even a desktop app would need to use wasm if they are using something like Electron which is basically just packaged-up V8/Blink. The issue is still download size. Each site that wants to use a different format will have to have it's users download the codec on first visit or cache expired. A better solution would be an extension where the codec is embedded and can be used on any site - but any webstore has the ability to block it, even for political reasons. A better solution would be to have a Media Codec API that would have a more robust middle-access to `img` and `video` tag processing, allowing a script to sit between, do it's processing and handle things like progressive rendering. Technically, all browsers could implement all their codecs this way and have lower security risk.

> If browsers had embraced modularity and layering instead of systematically killing them off (e.g. plugins), this JPEG XL debate and many others wouldn’t be happening. In theory, most plugins could be re-implemented as browser extensions, possibly using wasm today. Granted some, like Flash, were intentionally replaced by HTML5 features.

> In practice you can’t because of the overheads of repeated per-tab JIT compilation, per-site cache separation and so on. These things will have to have more thought going forward, possibly allowing for pre-compiling code and reusing it when using a Media Codec API. There are some privacy concerns like most things, but likely possible to speed up processing and having better caching for codecs.

I mean, if you were to use libjxl, you could deprecate usage of libjpegturbo and have less issues regarding binary sizes.

Yes, there is some stuff in libjpeg-turbo that is absolutely obsolete, like code to render jpegs in 256-color palettes

(which was a thing back when displays couldn't typically do full 8-bit RGB color, or TrueColor as they liked to call it then)

https://tldr.tech/newsletter/2022-11-04

That newsletter supposedly does have quite some readership, and it has a link to my blogpost

Reading that I guess my main takeaway from this article is that an awful lot of what browsers support is outside what the web was designed for. To quote info.cern.ch: > > "The WorldWideWeb (W3) is a wide-area hypermedia information retrieval initiative aiming to give universal access to a large universe of documents." And in this regard I would say that the web works exceptionally well. For almost any document viewing workflow, the web is probably the best tool that has ever existed, but on the other hand it is too built around the concept of pages for applications to work optimally. Taking JavaScript for example, that was really only initially intended for making fairly minor modifications to a page to liven it up a bit, and as such it is no wonder it isn't ideal for how it is used now.

An interesting insight might be how bit various parts of the browser are. I guess a few interesting metrics would be LoC, code churn, and usage (how often that code is actually run),

comments about jpeg xl

https://www.cufonfonts.com/font/dikta-neue-trial

https://hothardware.com/news/jpeg-xl-image-format-free-storage-but-google-isnt-having-it

have you read the last comment about libjxl 0.3.3 and aom 3.0 3.1

also https://encode.su/threads/3397-JPEG-XL-vs-AVIF?p=76888&viewfull=1#post76888

Hakan Abbas

<:BanHammer:805396864639565834> <:Google:806629068803932281>

Currently, the Linux version of Telegram has support for opening and viewing JPEG XL files

it is no different from my test by a few comments above. It's boring already, AVIF gives the best quality on overly compressed pictures, okay, is that all?

https://res.cloudinary.com/cloudinary-marketing/image/upload/w_700,c_fill,f_auto,q_auto,dpr_2.0/Web_Assets/blog/Battle-of-the-Codecs_fnl.png

has anyone from Google read at least something?

all the benefits of AVIF begin and end here

which telegram? binary from telegram site or packaged by linux distros or flatpak?

no idea, maybe SNAP

is it a jxl?

yep

is wikipedia banned in Russia?

wikipedia english like av1 and jxl

not at the moment. YouTube also works, but we are all ready to become china 2

I wrote a post... to troll

discord is so cringe

i can't view nothing

I'm in a browser, firefox nightly already supports both AVIF and JPEG XL

On the Windows 7 it crashes Firefox nightly

So i used the normal

use windows 10

Chrome joined three profiles but won't let me use YouTube

For security reasons

The new pc probably will be 729 euros i511th integrated igpu and 1tb sss

But i would wait before

Because Chrome will suspend the vulnerability on Windows 7 by january

<:Windows:806135372298977342>

Of course that's a chart made by me, so not exactly an unbiased source. Though I did at the time ask some Google people related to Chrome (and others) to review it and check if I was being fair.

Wow, is this your job? I checked it many times when I first saw it, and now, after years of tests, I can also say that it is very, very true

Thanks! It is not easy to make a fair assessment of things when you're involved in one of them, but I did my best.

https://encode.su/threads/3397-JPEG-XL-vs-AVIF?p=76921&viewfull=1#post76921 what do you say about such a test? I was slightly trolling making such a comparison, and yet it is significant, here -d 8.5

It is interesting to see what happens at such extremes, but for practical deployments, what really matters is performance at d0.5 to d4. There simply aren't many use cases where extreme degradation is acceptable. And you cannot extrapolate performance at very low quality to performance at medium to very high quality — which is something many people do nevertheless, leading to wrong conclusions by e.g. comparing a q10 jpeg to a low quality avif, seeing that the avif looks way nicer, and concluding that avif is better across the spectrum.

It surprises me that so far, in all tests of any kind, no matter who does them, no one talks about encoding time at all

I was wondering why there is no OPUS codec in bluetooth headphones, and only then I found out that OPUS is the most difficult codec to decode, the difference with the fastest VORBIS can reach 20 or more times

Opus isn't in Bluetooth because the Bluetooth IF only cares about proprietary codecs.

as much as browser politics sucks, Bluetooth IF politics are somehow worse and even less comprehensible

Opus also isn't particularly slow

it can be decoded and encoded on a single thread several hundred times realtime, which is *plenty* even for tiny embedded devices

I have been following LE Audio fairly obsessively for many years, to the point of regularly emailing people in the industry and all I know is that nobody knows anything

Google has also stalled adoption to an extremely unnecessary degree 😛

sounds familiar

it's very similar to jpeg xl. you have very talented people at Google whose research helped create the standard with very noble goals: hearing aid/accessibility improvements, + a bunch of other nice features that'd make it a licensing-issue-free audio profile that had a superset of all of the features of the many, many proprietary codecs and profiles the android team stalled support for a very long time, despite companies like Qualcomm investing heavily in supporting the tech. it seems like a pretty systemic Google issue 😔

Literally the point of opus was to achieve a probable, reproducible set latency suitable for webrtc. This whole idea of opus being slow is nonsensical

it’s a bit like this xkcd https://xkcd.com/1252/ but with speed instead of risk

“reminder: 20× slower than a blazingly fast codec is still very fast.”

https://www.twicpics.com/blog/why-the-web-needs-jpeg-xl

https://www.tellmebest.com/google-chrome-phone-pictures/

https://www.gamingdeputy.com/fr/le-format-dimage-jpeg-xl-pourrait-liberer-de-lespace-de-stockage-sur-votre-telephone-mais-google-ne-la-pas/

google is getting a lot of flack from websites for this

As they should

Isn't LC3 foss tho? <:Thonk:805904896879493180> Would've been nice to have opus in bt though <:ReeCat:806087208678588437>

lc3 is fraunhofer

there are foss implementations but you'd probably have to pay fraunhofer to use them in anything serious

Okay apparently lc3 is free to use but LC3Plus has a license fee

Not the worst ig

Here why Vulcan wishing there is more viable competitors in web browser engine sphere other than virtual duopoly of Google and Mozilla

So we can lessen dependency on one of them on emerging web technologies

Firefox has a lower market share than Safari

Market-share wise, only Chrome and iPhones matter

Yup

WebKit (and its fork like Blink) is synonymous with 'web browser engine', Gecko is the second thought (or afterthought)

Still disappointed that Opera killed Presto

I will always have a soft spot for KHTML

the original

On the train atm, can someone tell what he's saying about jxl? https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.youtube.com/watch%3Fv%3D1m9HxBlKgrA&ved=2ahUKEwjkkNaBwqT7AhUG7KQKHRR3C6kQjjh6BAgKEAI&usg=AOvVaw1jNr0WnVcuahWSdtlEBXQT

start at around 51:30

it's where he starts talking about images

still watching

he's somehow creating a progressive AVIF which is a little bit of an unfair comparison, as AVIF progressive doesn't work

he starts talking about JXL at 56:40

and he's *very* enthusiastic about JXL, technologically

he says that the biggest downside of it is lack of browser support, but since it's behind flags we can expect it soon

but overall he doesn't say much

and doesn't mention chrome's decision at all

Well that leaves room for chrome to reverse the decision without obsoleting that talk 😅

Jon's article in Russian https://habr.com/ru/company/skillfactory/blog/697756/

https://www.libertyrpf.com/p/351-amazon-belt-tightening-ftx-tsmc

Google vs JPEG XL lmao.

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

<a:smoge:824405057344503859>

> Helping the web to evolve is challenging, and it requires us to make difficult choices. We've also heard from our browser and device partners that every additional format adds costs (monetary or hardware), and we’re very much aware that these costs are borne by those outside of Google. So why not let them speak for themselves.

> When we evaluate new media formats, the first question we have to ask is whether the format works best for the web. With respect to new image formats such as JPEG XL, that means we have to look comprehensively at many factors: compression performance across a broad range of images; is the decoder fast, allowing for speedy rendering of smaller images; are there fast encoders Obviously they never used AVIF... 🤦

> ideally with hardware support, that keep encoding costs reasonable for large users So destroy another format just because it didn't get hardware support as fast as AVIF did? CDNs didn't even want to implement AVIF in the beginning because at scale it was so incredibly slow.

> can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format; do other browsers and OSes support it? We're already presented ideas. Talks of adding these features to AVIF broke down and they seem to have little interest in adding them.

I still need to see a hardware avif encoder that is any good for the web, even assuming that somehow web services get such hardware magically deployed. Typically hardware encoders make shortcuts to sacrifice compression for gate count. I am not sure if it would even beat mozjpeg.

At least he was honest enough not to bring up hardware decoding as something that matters.

I don't think they mean for the web, likely for cameras. I don't think hardware decoders would make any sense for images.

Bro, they also never used JXL <:KekDog:805390049033191445>

> We'll work to publish data in the next couple of weeks.

i think there will be avif-friendly benchmarking method that some people like to use, with the highest compression for visually acceptable quality and statistics on which format will take less space (and the others will be basically useless, because for users they will never be loaded first, if we assume the equal support in the browser)

Guest post by me coming soon in ComputerWeekly

This tweet got quite a lot of likes/retweets for a tweet by me: https://twitter.com/jonsneyers/status/1590485840563949569?t=pmx9-oszxw4fJw_c42K-Qw&s=19

someone should pay $8 to verify a google chrome account and announce jxl support 😆

https://www.computerweekly.com/blog/CW-Developer-Network/Cloudinary-clarity-Google-ditches-JPEG-XL-where-do-we-go-from-here

Ugh what is my face doing there

https://twitter.com/ABridgwater/status/1592230186690674688?t=8W8cWo7cqnJS04SaFI0P_w&s=19

A <:JXL:805850130203934781> logo or some <#824000991891554375> would have been a better image to put there than my face, lol. Oh well.

You are JXL.

J from JXL could also mean "Jon"

Jyrki and Jan also are or have been co-chairs of the jxl AhG:)

so when me & <@794205442175402004> were co-chairs, was it J(on) X L(uca)? 😛

Yes, I have been looking for a Xavier to join the effort but haven't found one so far

maybe playing a xylophone together would have worked

https://news.ycombinator.com/item?id=33646153 please upvote

scroll is messed up so i won't

oh, yeah. Hijacking scrolling is never good.

Wait what

In what browser?

every "scroll" event moves you exactly one heading up or down. firefox.

it isn't messed up for me, but this kind of thing often gets messed up in e.g. mobile browsers

is `scroll-snap-type: y proximity;` better? Or prefer to have no scroll snap at all?

changed it to proximity snapping, is this ok now or does it still feel messed up?

feels fine on mobile firefox

bit worse on mobile chrome

i'm not sure this is necessary, but it is at least a lot better than JS-based implementations of similar behavior

how about setting the title attribute on those software logos to the same as the alt-text?

that's a good idea