JPEG XL

Firefox is forgivable since they're a skeleton crew relative to June 2020, but Chrome is unacceptable.

This is the kind of thing I dislike: https://old.reddit.com/r/AV1/comments/yqed62/how_to_create_progressive_avif_images/ivq5d67/

yes, new format adoption is already hard enough — overcoming the inertia of "jpeg is good enough", the chicken-and-egg problem that nobody uses what is not supported and nobody supports what is not used, etc.

now we also have the potentially self-fulfilling prophecy of "not enough interest from the entire ecosystem" — there certainly is plenty of interest, but Chrome making a decision like that is a good way to make potential adopters lose interest

if they would have phrased it as "not enough ecosystem adoption _yet_, so we're waiting for that to happen before adding actual support (not behind a flag)", then that would be fair enough

but the way they phrased it seems more aimed at killing interest than at encouraging it

or maybe they have a very narrow view on "the entire ecosystem" as being basically "AOM and the Chrome codec team"

you won’t like this either then: https://www.dpreview.com/news/8294870350/affinity-photo-2-released-better-non-destructive-editing-new-masks-and-much-more?comment=5061959463

it wasn’t even the article’s main point

At this point, you have to wonder. Do people forget that development timelines exist? 😂

I spent way too much time on that and it still looks like a kindergarten composition, but whatever, it makes the point

not sure whether to laugh or cry

I think it would look more concise if everybody shared the same text bubble, just a single big pile

It's on slide 54 or so of https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/edit?usp=sharing, feel free to remix

I feel like having all of them use the same text bubble could be a bit dishonest

also I kinda like the distinction between those who just support jxl and those who directly want browser support

Do we have the right to share it on other platforms?

I noticed non-standard usage on slide 11: "costed" instead of "cost"

Sure! Let it go viral, lol

comic sans tho

That's because it's a clown argument

The commit adding the note actually got merged now

Review comments look kind of tone-deaf

fair enough

👍

IrfanView has updated libjxl as well. The updated plugin is available as an optional download.

It would be possible to put more icons into "We support JPEG XL" group but perhaps you don't have enough space there?

Feel free to duplicate that slide and add more 🙂

How hard would it be for another Chromium-based browser to support JXL, even though it will be dropped from the Chromium codebase?

Is it unreasonable to suggest adoption to other browsers like Arc from The Browser Company?

i think it's already works for any chrome and firefox-based browsers, just need the approval from the heads of these browsers and confidence that the libs and decoders will be maintained and not bring security problems

is there any **gui **to process hundreds of thousands of files using the advantage of terminal commands?

a terminal emulator <:lul:946531054485930015>

jokes aside perhaps emacs?

🙄

the efforts to get JXL "out there" remind me of the guy who fixed bufferbloat in routers lol. Little actual work on the algorithm, 10+ years and counting to spread adoption

There is still time! 👍

The sad thing is that since the announcement of jpeg xl - no one in the world is developing such a format, no one is competing. Only avif as part of av1 was made, and even then, it is extremely slow, and the competition is only on very compressed images

looks like their definition of "ecosystem" is "their own Google products"? Found this page again by chance (which says the interest was there lol) <https://chromestatus.com/feature/5188299478007808> > - Ecosystem interest in JPEG XL: Several Google teams evaluated using JPEG XL for storing and delivering images, as well as outside of Google: including CDNs interest in storing lossless-recompressed JPEGs as JPEG XL and converting to JPEG on request is the browser doesn't support JXL. Facebook is exploring to use JPEG XL.

<@794205442175402004> <@179701849576833024> It can be pretty much confirmed that the AOM devs are being involved in decisions regarding removing JXL from Chrome: https://chromium.googlesource.com/chromium/src/+/ec4bd43806b882b9faf155e413814aa0f809edcb

how does this commit confirm that?

It doesn't directly confirm that, so I will reword my statement.

it is kinda sus that everyone from author to reviewer is related to aom somehow https://www.google.com/search?q=%22aom%22+OR+%22avif%22+OR+%22av1%22+%22Vignesh+Venkatasubramanian%22 https://www.google.com/search?q=%22aom%22+OR+%22avif%22+OR+%22av1%22+%22James+Zern%22 https://www.google.com/search?q=%22aom%22+OR+%22avif%22+OR+%22av1%22+%22Wan-Teh+Chang%22

you can apply the same search query to the people cced in the merge request @ https://chromium-review.googlesource.com/c/chromium/src/+/3988999

tho Maurici Abad Gutierrez seems unrelated

hey, https://www.xnview.com/en/image_formats/ says that it supports writing in jxl, but when i open the drop down menu to choose output format, it's not there, any ideas/help?

linux, with version 1.96

"Currently not yet JPEGXL support on linux/macos "

oh, I use qimgv, but i would've liked to batch convert, i guess I'll have to wait a bit more

I have yet to look into that, but maybe that will be a good route, do you have any recommendations?

cool, I'll give it a try, thx

parallel can be simultaneously faster and more convenient

e.g. ``` parallel cjxl '{}' '{.}.jxl' ::: *.jpg ```

what options would you use, to achieve the same visual quality, but 60% smaller file size, as said on jpegxl.info? because I tried out xnconvert on windows now, and the default is very aggressive, it saved 92% on png files, compared to ~40% on lossless png transcode on the same 150 test files

compared to jpeg or compared to png? the 60% is for lossy mode compared to jpeg

i tried lossless on artworks (jpeg), but it didn't like it very much, overall 22% for ~50 files, the 40% smaller png-s are mostly screenshots

that seems exactly what the website says

my first guess on the lossy would be mozjpeg q90 vs cjxl d1

I just don't understand why the artworks would be so much bigger in file size in some cases, 200-400%

also, even though the losslessly transcoded png-s are smaller, they take noticeably longer to open and load, is that because of the image viewer I'm using or just the nature of jxl?

i think that's the nature of it

Lossy has been more optimized than lossless (since we assume on the web, lossy will be used way more)

yea, i noticed, that they (lossy) load faster, but i imagine it's just some time before a few optimizations arrive to lossless decode

Lossless is also inherently a bit slower, since it's just more information per pixel, and the prediction / ctx modeling is more complicated than for lossy

thx for the details, also for windows users: https://github.com/saschanaz/jxl-winthumb

Looks like it hasn't been updated in a while <:SadCat:805389277247701002>

it works though

makes sense, wouldn't use lossy on family photos, but for testing and meme pictures I shall try it out, also in xnconvert besides the quality slider theres the compression value, default for lossy being 7, could you clarify how compression would change the end file, I presume higher compression = lower file size and longer decoding time so, the thing that would help more is whether 7 is a sane default, and if not, whats the range to play around in?

AFAIK only cjxl can do lossless JPEG transcoding at the moment.

thank you

how much does the chrome team's dumb decision matter given wasm

libjxl can as well

but you'd need to have the code that does it

as far as I'm aware, no other libjxl clients currently have that implemented though

That's what I thought. Other programs don't use the feature yet.

I was also wondering, and would they consider re-enabling it given enough backlash and support from big parties, as seen from adobe recommending jxl for hdr photos

wasm is a lot slower.

speed is not too bad, but for HDR it will be a bit tricky, and of course it is a lot less convenient for the web dev to make it work

E.g. Cloudinary cannot deploy jxl via wasm since we don't control the html/js

For decoding typical web images it's not all that noticeable. Encoding is a decent bit slower, especially for large resolution images and modular. I am going to start testing the SIMD version soon, will let you know what the difference is.

what is Cloudinary

https://cloudinary.com/about

The company I work for 🙂

https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/0XA-0G6hBgAJ

> 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. 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, ideally with hardware support, that keep encoding costs reasonable for large users; 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? > After weighing the data, we’ve decided to stop Chrome’s JPEG XL experiment and remove the code associated with the experiment. We'll work to publish data in the next couple of weeks. > For those who want to use JPEG XL in Chrome, we believe a WebAssembly (Wasm) implementation is both performant and a great path forward.

Well I am curious what kind of data they have. It's a bit weird that they have been "weighing the data" but it will still take a "couple of weeks" to show it. That smells a bit fishy to me.

Jim gives quite a few criteria that are could be used to argue against lossy WebP and AVIF, and then somehow concludes that "the data" (which they cannot share just yet) is not in JXL's favor.

Compression performance: jxl is indeed better than the existing formats, so this factor is ok. WebP wasn't really (it's not that much better than mozjpeg). Fast decoder: check Fast encoder: check. AVIF does not have this (it can be fast but not good and fast at the same time) Can we optimize existing formats instead of adding a new format: no, jxl has unique features like lossless jpeg recompression, saliency progression, high-fidelity HDR, etc that just cannot be done in existing web formats no matter how much you "optimize" them. Do other browsers and OSes support it: this was certainly not the case with WebP and AVIF when they were added to Chrome...

"not enough ecosystem interest" was apparently dropped as an argument, and now the argument seems to be that it doesn't work well for the web.

Which is quite ironic imo since that was a use case that was extremely important in the design of jxl: it has progressive decode and minimal header overhead specifically because those are important for the web

imo the worst part is they can't even give a compelling enough reason why they would do something so stupid, because jxl is pretty poggers, so yeah, it really just feels bull, but google is abandoning webp2, so it's not as if it was dropped in favor of that, truly puzzling decision

It's dropped in favor of avif

There are many av1/avif devs/proponents in Chrome, including in the high ranking positions.

They need to block jxl if they want avif to get a chance of serious adoption...

monopoly is truly a bitch, introduced by microsoft, suffered by a lot since their practicies 😦

PSNR AND SSIM <:KekDog:805390049033191445> <:kekw:808717074305122316> <:KekDog:805390049033191445>

If I see one PSNR or plain SSIM analysis, I will go ballistic. Well, figuratively speaking.

https://tenor.com/view/whatarethose-shoes-gif-4488681

genuenly asking

Objective metrics used to measure lossy distortion performance. They are pretty bad at it on a human psycho-visual level, more so PSNR than SSIM.

well, if it's absolutely not usable in any way, it will definitely be used

Not just used, it will get an Emmy and become an Industry Standard™

should i even mention that the author, Jim Bankoski, leads the AOM efforts at google? lol > **Jim Bankoski** is a Distinguished Engineer at Google leading the team responsible for Google's video, audio, and image compression efforts. Theteam was founded when On2 was acquired back in 2011. Jim was the CTO of On2 Technologies. He has contributed to the design of all of On2/Google's video codecs from Tm2x through VP9, including video codecs widely used in Flash, Skype and now WebM. His team also works on hardware implementations and VP9 is now adopted as a hardware component by most of the major TV manufacturers. He is currently **leading Google's Alliance for Open Media Codec efforts at Google**, the major new open source codec under development. The AOM organisation now comprises more than 40 companies. source: https://www.cambridge.org/core/journals/apsipa-transactions-on-signal-and-information-processing/article/an-overview-of-coding-tools-in-av1-the-first-video-codec-from-the-alliance-for-open-media/5972E00494363BE37E3439FAE382DB10

last time I tried, it poops on transparency stuff

I'd like to say that it sounds like he is just their leading expert on image compression, and thus the correct person to make decisions on evaluating new codecs. On the other hand, he is a lead creator of the "competition", on which he has worked for a very long time, so it is easy to see that there could be some conflict of interest there.

i have no idea whether aom attacks jpeg xl or not btw, i'm not nearly qualified and connected enough to deduce anything like that perhaps they try to cram jpeg xl benefits into avif because their browser and device partners already support avif <:TVP_Marishrug:943099734267158558> who knows

Can they add benefits without breaking existing decoders?

(Or do they only actually care about the chrome decoder, and can thus change it however they want.)

formats like dng are constantly getting extended but, then again, different use and population target.

something that worries me is I have seen no one bring up the question of is removing JPEG XL from chrome a permanent decision or something that can be revisited 5 or so years down the line?

Let's first see what this "data" is that we will get in "a couple of weeks".

Btw I would also like to see the "data" that lead to WebP and AVIF getting enabled, for comparison.

And if they "weighed" the data, then I am curious how they did that, i.e. what were the 'weights' they used and why.

He's not the only one in Chrome who is an av1 proponent, there are a lot of them, many of them at higher positions within Google than the jxl folks. There is definitely some amount of conflict of interest going on, and escalating within Chrome will not help since the av1 proponents are also in the highest levels of that organization.

Independent scrutiny and arbitration is what is needed here. Any data provided by me or the jxl team in Google will only be seen — rightly so — as biased too. We need to see all the data, maybe do additional experiments to get more data, and get opinions from 'neutral' experts in the field.

One issue is that AOM has an influence on many companies, e.g. as far as I understand, facebook image engineers tested jxl and are enthusiastic about it, but they got instructed by higher-ups to shut up about it.

(facebook is a member of AOM)

Experts from JPEG will also not be seen as neutral, even if they were not involved in JXL.

So it's a good question where to find unbiased assessment.

The only one that pops to my mind right now is <@826537092669767691>

Intel and Adobe speaking out in favor of jxl despite being aom members and not at all biased towards jxl is imo strong evidence that there is value in jxl

Especially Adobe supposedly knows what they are talking about and doesn't pick jxl as the format of choice for hdr photography if they would consider avif - which already has browser support - an equally good solution.

Google account is needed, and I can use my @cloudinary.com address because it's using Google Workspace. I assume Intel doesn't use Google Workspace.

When I saw that and other messages from @gmail.com I also thought that a "troll" could make an account and post as somebody "important".

Sure, but it would be relatively easy to check and get such an account removed due to violation of terms of service if it's an imposter.

BTW, for those who aren't in the know, this isn't the 1st time Chrome has preferred caving into internal politics over user comfort and experience regarding codecs. To this day, Chromium has inferior VP9 decoding performance vs Firefox because Chrome uses libvpx-vp9 for decoding while Firefox uses ffvp9. Same thing on Android for AV1 with libgav1 while using dav1d in their own browser.

to be fair in this regard, libvpx-vp9 has more feature support than ffvp9, such as alpha

although they could always use ffmpeg's parser to check if it has alpha and if so, use libvpx-vp9 and ffvp9 otherwise

Not using the best implementations is one thing. Killing a codec that is great for the web and has good ecosystem traction just to avoid it outcompeting the image version of their favorite video codec — which they don't even need to be a success for the video codec to be a success — that's imo a new low.

isn't ffvp9 GPL'd?

OH, I might have forgotten about that 😂 Let me check the licensing for the decoder specifically. Now I remember why Vorbis didn't become as widespread for the same reason.

I don't believe it is

ffmpeg itself is LGPL no?

LGPL yes

which, as chrome is typically statically built, makes effectively no difference (I think)

chrome uses FFmpeg for other things though, as far as I'm aware

seems to, but perhaps they do some special things for it

yeah they seem to compile it to a dll

just checked, a baseline lgpl build of ffmpeg includes vp9 so it's not GPLed

still LGPLd though, and I could very well imagine preferring the Apache impl or something like it

this is invalidated by the fact that they *still use FFmpeg*

No, it is LGPL 2.1+.

Mozilla's fork: https://hg.mozilla.org/mozilla-unified/file/tip/media/ffvpx

someone should make something like this <https://www.battleforthenet.com/> for jxl and post it on reddit

In the recently released GIMP 2.99.14 we have import/export of Exif, XMP metadata for JXL images.

Nice!

uncompressed only, or also `brob`?

Export is uncompressed only. Import is via libjxl API, in my cases it worked with compressed Exif too.

nice

I wonder if it would be a viable strategy to try to convince chromium and firefox forks to enable jxl support...

Very viable.

MS still hasn't added AVIF support to Edge, it's been long enough that it feels intentional

I'd say 50/50, because they've mostly stepped away from the web stuff (Couldn't compete with Google either), and it's not like they need to worry about upsetting partners if they add it to Office

They also haven't added "first class" AVIF support to Windows, it only gets it through a combination of the HEIF filter and AV1 plugin for video

supporting jxl isn't a betrayal of aom and anyone who thinks that it is should get the fuck out of aom

yeah, it's pretty stupid. One is perfect for video and one is perfect for still graphics.

Are there any performance caveats besides this? A webpage with lazy image loading should perform just as well, right? I imagine it could be noticeably slower with hundreds of images loaded at once, which is not a good practice anyway

Well it will decode properly, it just won't display.

And so begins the fallout of Google's disasterous decision to set the planet back from practical technology.

https://twitter.com/jonsneyers/status/1592632715249324032?s=20

the voting microservice is having issues <:kekw:808717074305122316>

The more I reflect on this and observe the public and backchannel discussions that are happening, the more I'm convinced that this is the root problem: https://twitter.com/jonsneyers/status/1592797329773694976?s=20

Meanwhile, I'm hoping for the poll to break out of my twitter bubble so it reaches some people who are not seeing it because they're jxl supporters who follow me:

i remember the time on internet they wre 2704x4608 images

google simply don't want you need to accept

don't want lossless enabled on a browser

and also the problem with banding and efficiency

on reds there's a lot of banding on every jxl image

but i don't think is that the reason

they probably want to push avif2 from av2 codec

getting outside my bubble, as expected the number of "good decision" and "don't know" votes are rising faster now

I think chrome devs are starting to answer now, the amount of "good decision" votes is going up

Yeah, they likely *have* to answer yes or get reprimanded.

"bad decision" dropped just below 80% of the non-abstention votes (it was above 90% initially, but that's just because I probably have disproportionally many jxl supporters amongst my followers on twitter)

getting close to 1000 votes now, might start to become representative

https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/xX-NnWtTBQAJ I posed the 'elephant in the room' question...

Now at 78% 'bad decision' vs 22% 'good decision', at 1229 votes (where almost 2/3 of the respondents didn't know or just wanted to see results, but that's still 400+ people who did have an opinion)

With 1500 votes in, we are at 77.7% "bad decision" and 22.3% "good decision" amongst the 35% who had an opinion

Jxl needs more advertising

Quite often people requested HEIF support because they made lot of photos on their iPhones in HEIC format. It would be fine to have Camera application on smartphones, taking excellent photos and saving in JXL. It could manifest high bit depth and HDR qualities of JXL.

No one is going to install huge gallery qt app just for jxl. aves (https://play.google.com/store/apps/details?id=deckers.thibault.aves) would be a better choice but they don't implement it yet.

I just made a page: https://jpegxl.info/why-jxl.html

maybe looks a bit too "corporate marketing" style, but perhaps people like that

Is it possible to colab with popular youtube tech channels? something like this https://www.youtube.com/@ColdFusion and ask them to make a video about jxl and its benefits.

that would be cool — but maybe other people than me should do that, to avoid it looking like Jon's codec with only one person pushing it

I thought the J in JXL stood for Jon. <:kekw:808717074305122316>

Has anyone submitted patches for Firefox to support JXL animation/transparency/hdr/color profile/progressive decode?

Because atm firefox does not support any of those things in JXL

Even in nightly

Patching that stuff into firefox would also help with designing and debugging the decode API for libjxl I imagine too

there are ignored pending patches for animation, transparency, color profiles and progressive but nothing for hdr

me and a friend compiled a build with them and they seemed to work just fine

pretty sure firefox only supports JXL in case chrome turned on support by default

<@1028567873007927297> if you really want to test here is a build of waterfox (firefox fork with little changed) with all the pending JXL patches merged in https://drive.google.com/file/d/1fsNdPqyfSqON6_AsTXtINBXSgVCaLPRx/view?usp=sharing

like I said everything should work expect HDR

I don't remember but you might need to turn off updates in about:config or else it will try to update to a official build of waterfox without JXL support

actually not sure if firefox supports hdr at ALL atm so maybe that's why

How's waterfox different than librewolf?

if you want firefox beta with my patches, here https://dist.grass.moe/firefox-108.0.en-US.win64.installer.exe

have linux builds?

uhh if someone will actually use them

my windows firefox also includes video deband + 3dlut

i would

Good to hear that it's already been patched but what the heck is up with their excuse of a "lack of manpower" to review and merge such patches? It's a very small diff right?

It's weird how they are twiddling their thumbs and dragging their feet.

And thanks <@245794734788837387> for patching it!

we just dont know, <https://phabricator.services.mozilla.com/D119700>

they need to allocate someone to be responsible for whatever bug reports come and to manage any ongoing changes i suspect

and to review relevant patches i guess but its probs something something management not seeing enough value

probs in lines of "we're sucking with avif already in some ways we cant take on another format especially when others dont seem to seriously be pushing it yet"

it's so typical for current year management to oversimplify tasks as something that just need more resources and things lagging behind as just something not being given enough resources and totally not things being sucky enough to require actually more effort than is being estimated & overall not giving enough freedom for developers to decide on their own how to use their time

its silly but kinda predictable with large enough teams like mozilla's

Doesn't really feel like an open source project at all. Neither does Chromium.

Sounds like rule by corporate board masquerading as "open source project lmao"

And the funny thing is Mozilla basically already fired everybody that was contributing anything of value such as actual working code

like all the devs working on servo

All that's left of mozilla is some weird skeleton crew consisting of a corporate board that decides how to make more money by selling out more rather than making things better

hmm, but that's enough of my rant.

so any feedback on this page? if there's something that can be improved/tweaked/added, feel free to say it here (or make a pull request with the changes)

i think the replaceable legacy jpeg decoder is worth mentioning (less libs, better quality, etc.) so it's also legacy-friendly and *libjpeg can be completely superseded by libjxl

well the page is for jxl the image format not libjxl the library

so mentioning that could be considered out of the scope of that page

but still, since a lot of things from the old jpeg overlap in jxl, which means it's easier to do backward support it's not quite like jpeg xt, but much closer than jpeg 2k, for example

Add animations or animated bar graph that shows web page loading performance when using jxl vs old formats like webp and jpg.

I like the idea to illustrate web page loading, maybe a 'film strip' comparison could be good. e.g. progressive jpeg that takes 500ms before first preview, 1.5s to show full image, incrementally loading webp that shows the top half of an image at 500ms and the full image at 1.2s, avif that shows nothing and then suddenly the full image at 900ms, and then a jxl that shows the first preview at 200ms and the full image at 700ms

No idea how to visualize that in a sufficiently simple way that doesn't take up too much space, animated or static

meanwhile I tweaked the layout a bit and added a section on software support to https://jpegxl.info/why-jxl.html

final poll results:

is libjxl really suitable to replace, say, mozjpeg as a high-quality jpeg DECODER library?

I imagine mozjpeg is probably faster at decoding old-jpeg

But does libjxl produce higher quality output when decoding old-jpeg?

Does it have any advantages over let's say mozjpeg, as an old-jpeg decoder?

(Aside from getting a jxl codec and old-jpeg in one lib)

AFAIK mozjpeg advantages are only on the encoding side, decoding is the same as jpeg-turbo

I thought mozjpeg is a (marginally) slower and higher quality decoder than turbo

as well as encoder

I'm not familiar with mozjpeg specifically, but I do know that libjxl is a particularly good decoder for legacy JPEG

whether or not it beats mozjpeg I can't say as I don't know mozjpeg's decode side

It definitely beats TurboJPEG though

well mozjpeg call itself "Mozilla JPEG Encoder Project"

https://bugs.chromium.org/p/chromium/issues/list?sort=-stars%20status%20opened&groupby=&colspec=ID%20Pri%20Stars%20Component%20Status%20Summary%20Modified%20Opened%20&q=component%3Ablink%20stars%3E399&can=1

a few more stars and we're in the top-30

(of all time)

in the list of open issues only (not historical ones that are closed already), we're at number 4: https://bugs.chromium.org/p/chromium/issues/list?sort=-stars%20status%20opened&groupby=&colspec=ID%20Pri%20Stars%20Component%20Status%20Summary%20Modified%20Opened%20&q=component%3ABlink&can=2

out of 16303 currently open Blink issues

https://bugs.chromium.org/p/chromium/issues/list?sort=-stars&colspec=ID%20Summary%20Stars&q=opened%3E2019-01-01&can=2 # 3 in all opened issues opened since 2019-01-01

haha, well they did add HEVC support (for those who have hardware decode for it), so who knows maybe they'll add BPG too then 🙂

what about something like this?

like this. https://www.youtube.com/watch?v=Vz3CCBZWkG8

what do you mean? make a youtube video?

No

This is enough

I think it's about something like this https://blog.playcanvas.com/wp-content/uploads/2020/10/Kapture-2020-10-13-at-15.48.40.gif

or this, but in a more cartoonish simplified way https://youtu.be/inQxEBn831w

added an animation

to https://jpegxl.info/why-jxl.html

made by doing a screen capture while actually loading https://sneyers.info/progressive/webp-jxl.html in Chrome at simulated 3G speed

I did a static render of https://jpegxl.info/why-jxl.html well it was actually <@146411656174501888> who did the rendering part since when ever I tried to render it the bottom of the image would be messed up for some reason

was originally gonna export it as a lossless webp but I ran into the image dimension limitation of the format

I am getting good vibes today in private conversations regarding adoption. Can't share much yet, but I got good vibes regarding jxl from 3 important players today.

new players who haven't announced their adoption before?

Yeah

tried converting that to jxl but my phone OOM'd 😔

as a lossless jxl it's less then half the size

> This is a fun moment in the web browser industry. **After more than a decade of total Chrome dominance**, users are looking elsewhere for more features, more privacy, and better UI. my sides

i don't see how this is a chrome competitor

It isn't

It's downstream from the same code that Google controls with an iron fist.

But most people aren't aware of things like that

Firefox (and other Gecko-based browsers) is the only one that is not controlled by Google or Apple

Everything else is basically various skins for chromium and safari

I guess non-safari webkit is also a thing in principle

Most switched to blink/chromium afaik

In theory e.g. Edge or Opera could choose to keep the jxl code and enable the flag. In practice they are unlikely to deviate from upstream, I think.

kHTML still exists

but I agree, it's oof

I want to know what happened to EdgeHTML.

isn't webkit based off khtml?

it's a kHTML fork, yea

not for much longer: > KHTML is set to be removed in KDE Frameworks 6.[3]

[3] https://phabricator.kde.org/T11543

(arguably, that should be https://phabricator.kde.org/T11542)

one frustration with chrome's nonsensical decision is it affects Electron

so discord's not gonna get JXL support

Everyone is fucked basically because everyone has continued to foolishly base everything upon Chromium for the last decade or so despite all the warnings from people concerned about giving them too much power and not enough variety/competition

Yes, the web platform is supposed to be defined by consensus, by W3C and co. As it is now, basically Chrome has veto power, and also has power to push things that the others don't want (e.g. WebP) by pushing websites to use it (through search rank impact) so some will use it without fallback and then the other browsers are basically forced to implement it too if they don't want to look broken...

WebP/AVIF benefit a lot from the current definition of LCP, which ignores progressive loading, so it makes progressive JPEG look worse than it actually is in terms of UX. And websites need to optimize for LCP because it impacts their search rank, regardless of whether the metric actually captures good UX.

Mozilla has yet another place where one can request and vote for JPEG XL support; connect.mozilla.org https://www.reddit.com/r/jpegxl/comments/yzdycq/support_jpeg_xl_mozilla_connect_ideas

proud to have pushed us to this milestone \:)

on another note, does starring the issue really do anything to help it gain more attention, though?

other than being just a show of support overall

https://discord.com/channels/794206087879852103/794206087879852106/1037311643656388688

thanks!

Next step: 444 Can't have it stuck at 420 😅

640 ought to be enough for anybody. Otherwise it will grow to 666...

This is basically the story of how a joke format like "weppy" was shoved down everybody's throat.

if only they did that for a format with actual potential

Lossless webp is quite nice, too bad it suffers from the 8-bit limitation and the max dimensions...

Lossy webp is not really an improvement compared to mozjpeg though, and firefox was right to keep it out as long as they could. Now it is an unremovable part of the web platform and will soon cause unnecessary bloat in all browsers since only legacy pages will still use it.

but adopting webp in other browsers when the next gen formats are available (or close to it) was not worth it, even vp8 is hardly used anymore

I agree, but too many websites are using webp without fallback so firefox/safari basically had no choice: if a page doesn't work on chrome, that's a problem for that page, but if it doesn't work on firefox, that's a problem for firefox...

I wonder if someone from Chrome will bother to reply to my "elephant in the room" question (https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/8zzn4E39BgAJ)

Lol <@826537092669767691>'s analogy is quite on point: (https://news.ycombinator.com/item?id=33664777) > WebP is like a magic backpack that makes your baggage 5-10 lighter — by having a hole and dropping your items.

looks like things are going well (i guess?) over at firefox ideas

Probably an automated message though.

https://webkit.org/blog/13584/release-notes-for-safari-technology-preview-158/ Looks like it is in fact possible for Safari to add support for a new image format without OS-level support for it. Can we get them to do this for jxl?

the only problem with that is apple, they wont add support for anything especially after they have chosen heic, they'd rather stick with something meh than change for better, admitting that there is something better than what they use is not a very apple move

Well they are adding avif

They love heic, because they're the only people on the planet with an architecture that makes hardware decoding of still images viable

They need heic with 512x512 tiles though, I think... So even regardless of patents, good luck with that, when there's no guarantee that the images will follow that tiling convention

yeah, but who's making heic images? Mostly Apple.

apple living in it's own world, as always

Hence all the visible tile borders when you tell it to "visually losslessly" convert your JPEGs to save space 😂

This whole discussion about third party libraries in Safari is pointless. If they want JXL support, they will make it happen, if they don't, they won't.

(also safari doesn't support HEIC)

this is true

Of course things will only happen if they want them to happen. It's just that Safari always used the excuse of OS-level support being a precondition, so it was "not under their control", and now we do have a precedent that at least technically, they can just take a Webkit-supported format and make it work in Safari too.

Yeah, but my understanding is that it's just a temporary measure for compatibility with old macOS versions. They added OS-level support for AVIF in Ventura, which coincided with that Safari release.

Sure. But it means the "needs OS support" thing is a philosophical thing, not a technical limitation. I didn't know that.

inbefore Firefox gets JXL support and Chrome doesn't. Imagine Chrome having worse performance metrics because they aren't using JXL <:YEP:808828808127971399>

Yes, Apple set a precedent and demonstrated that Safari can add codec support independently of OS-level support. Everyone should have already known they were lying to us but now they have themselves just proven they were lying all this time

I thought everyone already knew that

https://issuetracker.google.com/u/0/issues/259900694

would be an interesting situation if android supported jxl and chrome not

I don't have high hopes that Android will move quickly on this, and in any case there's a very long tail of old Android devices that don't get updated so this is long-term stuff...

JPEG XL works great in a CSS-based browser program for combining tile image (in firefox)

are there any diagrams available showing effort/encode time and effort/filesize?

someone asked about encoding/decoding speed on the issue, so maybe info about that could be added to the description

https://jon-cld.s3.amazonaws.com/test/atradeoff-absolute-SSIMULACRA_2_modelD.html

That's bpp vs ssimulacra2 on the left, ssimulacra2 vs speed on the right

This is the same but plotted as ssimulacra2 vs relative filesize saving compared to libjpeg 444: https://jon-cld.s3.amazonaws.com/test/atradeoff-relative-SSIMULACRA_2_modelD.html

More metrics and plots here: https://jon-cld.s3.amazonaws.com/test/index.html

https://twitter.com/jonsneyers/status/1472959101416226823?t=B4Rd2tnZ9j0AzruP8zRd7A&s=19

That's for lossless with fjxl

what cjxl option allows for exif passthrough?

it's supposed to preserve exif by default, if it doesn't, open an issue please

it's up

no, I wasn't aware of that, but I have it installed

the original exif metadata (with date taken and camera info etc) doesn't get copied

JPEG XL image, 632x632, (possibly) lossless, 8-bit RGB Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Perceptual

well, i did it with roughly 200 files, and none of them retained any exif data

but here's one

this discussion is better moved to <#803663417881395200> , but try updating cjxl to latest git version. I think 0.7 doesn't do metadata.

In light of the Chromium decision, has anybody considered an online piece (e.g. blog post? single-page site? infographic) that clearly communicates how much energy and emissions and hardware and land use and water Google is wasting, by rejecting JPEG XL? (e.g. taking the difference from a projection of Chromium as status quo, compared to Chromium with JPEG XL adoption)

that would be a nice angle to give them a push to reenable it

well, servers have to deliver less data, but the encode takes more power, all in all storing less data is cheaper than the initial encode cost

Simple: you compare encoding and decoding speeds at X power draw. Storage power costs would not be a great argument as AV1 intra and JXL have similar performance generationally speaking unless at the very high end or the very low end.

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

<:SadCat:805389277247701002> ```Then the JPEG XL image data is transcoded into JPEG image and cached using Cache API for faster subsequent page views```

<:galaxybrain:821831336372338729>

I would hope he's using a very high quality JPEG and just using that instead of uncompressed buffers to avoid wasting too much cache, but still, it feels like an approach that doesn't generalize very well — e.g. what with alpha, animation and HDR?

they use the term "transcoded" so maybe they don't know that only some jxl files are able to be directly converted into jpegs

although I'm not sure

https://www.palemoon.org/releasenotes.shtml

First browser with jxl support!

<:FeelsAmazingMan:808826295768449054> <:JXL:805850130203934781>

woah that's amazing

how good is the implementation? does it support progressive? how does it handle HDR?

i'm gonna test it

enabled by default, with all patches (because it's firefox-based) and features?

uhhh something seems wrong

are the colors inverted?

this is what happens to HDR images for me

more HDR images

also there seems to be 0 progressive support

anyone have a good testcase website for alpha support?

I think there might also be no support for alpha

this isn't good....

so much isn't working

does firefox have hdr support at all? and yeah, it might be better to release something like a beta version for testing first

firefox doesn't have hdr support however there are unmerged patches that add working support for alpha, progressive and color profiles

looks to me like it is treating RGB as BGR?

https://repo.palemoon.org/MoonchildProductions/UXP/pulls/2025

no one was there to push them in the right direction, their implementation seems to be based on firefox's current implementation which only has basic support for jxl

maybe someone could point them to the unmerged patches for color profiles, progressive and alpha support along with letting them know that currently all the colors are messed up

did they not test it lol

looks like the test was very basic: does something load or not? 🙂

anyway, if there's a will to support it, we can get the bugs fixed

me and a friend might try to fix it however no promises we will get it done

maybe

the same wrong colors 5 months ago <:KekDog:805390049033191445> https://repo.palemoon.org/MoonchildProductions/UXP/issues/1769#issuecomment-30968

I never saw that before — did nobody compare the image with how it looks in Chrome?

something that doesn't help is it seems like they only checked if the images at https://jpegxl.info/ and https://jpegxl.info/art/ loaded and nothing else which is bad because if you don't know what the images should look like they don't look all that wrong

<@794205442175402004> could a subpage at https://jpegxl.info/ be made that just holds good testcase images with correct renders in png form next to them?

Yeah we should add a test gallery of normal, photographic images there

Ah a test page where you can compare to another format is also a good idea

a Compass is a good image to test orientation compliance rather than bench_oriented

since a compass is really obvious if it orients correctly

north points up

Even just an Arrow pointing up with some text like "This Side Up"

or even a photograph of a box with that

text would detect incorrect mirroring

Uh-oh... Palemoon has borked colors 🙁

yeah and it also doesn't support progressive decoding, color profiles and alpha transparency

it's based on firefox's current implementation

which is only basic jxl support

although i'm not sure how they messed up the colors

Could be little endian vs big endian or something

RGB vs BGR

Confirmed, I've just swapped R and B in GIMP and it looks correctly

left = firefox right = palemoon

I wonder why did they change the surface format from "R8G8B8A8" to "B8G8R8A8"

also from looking at this it seems like it might be really easy to port over the unmerged firefox patches for progressive decoding, color profiles and alpha transparency!

Great! Would be nice if we can point people to a browser where jxl just works

Making HDR work will likely be harder since I assume they don't have any HDR rendering

Can we find a chromium fork and convince them too to enable jxl?

too bad i get this when trying to build palemoon lol, gotta figure this out

maybe vivaldi? although i'm not sure if they would listen or care especially since I don't think they make any changes to chromium's core and it seems like they probably want updating between chromium branches to be simple

forgot to enable pinging on my reply above so ill just do it in this message just in case <@794205442175402004>

Vivaldi won't care

oh I know a browser that might care

Brave

they might actually care about jxl

and I think that some of the changes they make might be lower level then what Vivaldi does

Palemoon is a very unserious effort, so bugs like these aren't surprising.

iirc they already said they wont support it if/when chrome drops it

I believe you but where did they say this?

We can offer maintenance support for chromium derived browsers that want to keep jxl support, I think. After all, it were <@795684063032901642>, <@768090355546587137> , <@179701849576833024> and co who actually wrote the code to make things work in chromium — so they can probably maintain it better than the chrome media team itself. If that would be the concern for browsers like Brave...

https://community.brave.com/t/does-brave-support-jpeg-xl-or-jxl-since-google-has-now-axed-it-from-chromium/442458/3

oh also I forgot to mention that another thing that's unsupported by palemoon that's fixed in the unmerged firefox patches is support for animated jxl files

I found out why the colors are messed up in palemoon

Issue #1769 - Part 3: Cleanup nsJXLDecoder.: ```"I've decided to abandon the OS_RGBA backporting effort and instead went for using OS_RGBA's value which is R8G8B8A8. Turns out that there is much more going on in Mozilla's version of CreateSurfacePipe than I've expected, like the aInFormat and aOutFormat thing which I really don't want to delve into right now. Looking at the code it looks like all JPEG-XL images are expected to have an alpha channel anyway, so I think my workaround should be safe."```

Yes, very likely we will prioritize helping them get it right 🙂 We will talk about this tomorrow in the team.

i did change this back but it seems like the browser doesn't even display the image when this is set lol, probably a deeper underlying issue maybe

I am the author of JXL.js. This is the reason why I am transcoding JXL to JPG - to save the cache size. The default JPEG quality is 92% in Chromium: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/image-encoders/image_encoder.cc;l=85

Is decode so slow that caching is needed?

Unfortunately, yes.

I'll be experimenting with WASM decoder from libjxl, which supports progressive decoding, but requires SharedArrayBuffer: https://github.com/libjxl/libjxl/tree/main/tools/wasm_demo

Cool, let us know if there is anything unclear or if you have suggestions for improvement...

Check out the some more documentation added very recently: https://github.com/libjxl/libjxl/commit/89b17796f31f9246fc473d406aa1921fc1434d02

AFAIK, you can't avoid `SharedArrayBuffer` usage if libjxl is linked with `-pthread`, see: https://discord.com/channels/794206087879852103/1036951308294434857/1043603369505345536

Thanks, I'll try to rebuild it without pthreads and compare the performance.

I made a WASM build with `USE_PTHREADS=0` and uploaded it here: https://niutech.github.io/jxl.js/libjxl/nopthread.html but it aborts in function `jxlCreateInstance (jxl_decoder_nopthread.wasm:0x1712)`. Does anybody know why?

By default, the Wasm demo uses 4 worker threads in the parallel runner, you can try changing that to 0 here: <https://github.com/libjxl/libjxl/blob/8bf8deb95d0fc8ca86cb147f0b138f6e42748e94/tools/wasm_demo/jxl_decoder.cc#L53> (untested)

However, that will probably affect decoding performance. You could also try experimenting with passing `JxlThreadParallelRunnerDefaultNumWorkerThreads()` there and using `-sPTHREAD_POOL_SIZE='_emscripten_num_logical_cores()'` (or `-sPTHREAD_POOL_SIZE='navigator.hardwareConcurrency'` if you only target web) as linker flag.

(since `std::thread::hardware_concurrency()` would end-up calling `emscripten_num_logical_cores()`)

https://twitter.com/ProgramMax/status/1596830604275785728?t=G39pSsQXGGZ6OjIq5MA4pQ&s=19 interesting interpretation...

Um... what?

and that's why AVIF was enabled on production releases from the beginning with no experimental period

https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c235 > I would agree with what others have said here, dropping JPEG XL seems like a poor choice in terms of usability & sustainability. Frankly, it seems outright hostile towards all the businesses and users who are invested in the format.

Unfortunately not a person with great power in Google 😅

https://www.linkedin.com/in/joseph-marques-8b6614133

Still, good to hear voices from within Google also opposing Chrome's decision.

Intern

Tomorrow: Former intern.

no, the internship was in 2019

I sent the JXL image via Telegram from Linux to iPhone. The iPhone user was unable to open the JXL image but at least preview was displayed.

and on other systems?

i'm guessing telegram generates a thumbnail in some common format (png?) on the sender side and includes it in the message

Well, the very presence of a preview is understandable, this is part of the telegram system -- the preview of the file is into the message itself in the form of 100-200 bytes JPEG (headless), at the same time, the LINUX version of telegram may already have JXL support to create this preview.

where do these 20 new comments from? https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c236

looks like someone outside Google is trying to "Revert "flag_descriptions: Add note about JPEG XL removal"" https://chromium-review.googlesource.com/c/chromium/src/+/4061563

might have been a small or private community or group of firends who became aware of the chrome situation

yeah could have been some discord group or whatever, I cannot find anything public that would explain it

yeah it's better to avoid such comments

they can only be used as an excuse to close the discussion

the value they add is counter to the argument of "nobody cares"

ah that last comment gives a clue

https://st-just.tumblr.com/post/702181015949574144/koito-yuu-hello-tumblr-users-do-you-hate-webp

this is where they come from

the quotes in comment 255 made me find that https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c255

I guess this is the original post: https://koito-yuu.tumblr.com/post/702180866748809217/hello-tumblr-users-do-you-hate-webp-files-well

"this would make it slightly cheaper for them to create scrolling previews on youtube videos." -> I very much doubt that this makes any difference. Youtube previews are typically separate images anyway (no big channels use the auto-generated ones, they upload custom ones), but even if they are auto-generated, they don't just extract a frame from the middle of the video, they downscale it as well so it needs to be re-encoded anyway.

Moreover, the videos for which they would use auto-generated ones (so mostly the long-tail ones from smaller channels that don't bother with custom preview images), would not be encoded in AV1 in the first place, since AV1 encoding is too expensive to just do on every video 🙂

It's interesting how people are trying to find a justification of the form "Greedy Google can make more money by disabling jxl!" but I really don't think that's what's going on here 🙂

popcorn worthy comments

opened an issue here: https://github.com/facebook/fresco/issues/2696

So tomorrow they'd be a former intern. I see nothing wrong here. 🤓

https://twitter.com/hn_frontpage/status/1598008330605166598?t=KaRAw0-egOsglvrp0dN0ag&s=19 lol this made hackernews frontpage and then they realized it's not that meaningful 🙂

got swiftly flagged, as expected and as it should.

Yeah. I wonder why chrome is not just quickly closing that pull request. It confuses people...

It's kind of funny pull request activism, it would be interesting to see what happens if every time they remove it, people make pull requests to bring it back. But I suspect they would just lock it somehow.

Anyway, I wonder how exactly they're going to remove it in M110. In the current canary version of M110, it's not removed yet. I wonder if they will just expire the flag at M110 instead of the current expiration (M115), or if they will actually remove the code already.

If they just use the usual flag expiration mechanism, you can still unexpire the flag for a while, so it gives some extra time. Anyway, support behind a flag has only limited usefulness...

So jxl is rrmoved?

Chromium team is in good relationship with logic. Hide feature behind flag -> say nobody uses it -> remove feature

They are planning to remove it in M110, which is scheduled to be released on Feb 7th 2013.

But we will see what actually happens. The backlash has been quite strong, they haven't published the data yet that supposedly justifies the decision, and the actual change that will disable the flag or remove the code hasn't been merged yet, so far it's only a note in the flag description.

Speaking of which, what exactly is the range of time intervals that can be said to be "a couple of weeks"?

2013?

Lol I mean 2023 of course

https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/xX-NnWtTBQAJ was written on Nov 11, almost two weeks after the decision, and promised "We'll work to publish data in the next couple of weeks."

That's almost 3 weeks ago now.

They sure need their time to put a nice layout on all that data they supposedly carefully analyzed and weighed prior to the decision

I wrote "the case for jpeg xl" in a few days, and I am just one person. They have a team of hundreds of people and after a month we're still waiting for a "the case for not jpeg xl"

We reached 600 stars on the blink bug. That's position 4 in the open bugs: https://bugs.chromium.org/p/chromium/issues/list?sort=-stars%20opened&groupby=&colspec=ID%20Pri%20Stars%20Component%20Status%20Summary%20Modified%20Opened%20&q=component%3Ablink&can=2

26 more and we're in the top 3

24 now

It's harder an takes longer if you make the decision first and come up with the data and a valid reason for your decision second

No.

moderators *can* add a post flair

which is to my knowledge the most used way to handle this kind of situations

I don't have much moderator power on that reddit, it was started by someone else

4 left

5 now, since the current number 3 also gets extra stars 🙂

Such interesting stuff. It's like watching counting votes at the end of elections.

Now 3rd

With Farnsworth's voice: Good news everyone! Now we have third most starred chromium issue.