JPEG XL

4-page article on <:JXL:805850130203934781> in April issue of iX Magazin (German) : https://www.heise.de/select/ix/2021/4/2101218031038914464

(I got invited to write an article for that magazine after they wrote something short about jxl on their website and it got a lot of comments: https://www.heise.de/news/JPEG-XL-soll-JPEG-PNG-GIF-umd-Webp-beerben-5022986.html)

heh, I thought this was going to be a channel about code coverage

There's a channel description to make it clear what kind of coverage this channel is about 😆

Article on Microsoft's rANS patenting attempts: https://www.theregister.com/2021/03/13/microsoft_ans_patent/ (some talk about jxl in the comments)

`media coverage`?

yes but also wikipedia, forums, blogposts etc

~~test coverage~~

11 months old video "JPEG XL - format of the future, solution of everything" (Czech language, length 12:28): https://youtu.be/HCcYssKAvFs (I found it yesterday.)

https://www.danisch.de/blog/2021/03/18/bildformat-jpeg-xl/

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

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

3 authors one new for italian

https://es.wikipedia.org/wiki/JPEG_XL this probably will be fixed software will be removed because of risk of spam

the en is this the same

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

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

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

if there is any new language do not add the link but tell here with a -

or hide the banner

Added a Dutch one: https://nl.wikipedia.org/wiki/JPEG_XL

🤔 <https://ja.wikipedia.org/wiki/JPEG_XL>

oops assumed those would become actual newlines

Can the magic number at the start cause epilepsy ?

fixed it

When creating Polish version I didn't even use that crappy translation tool, I used full-manual text source editor so I could hand-pick Polish version of all templates, hyperlinked articles etc, scrap some things and add others in return etc.

For example infobox and references *completely* broke down when I used Wikipedia's autotranslation tool, because it couldn't find Polish version of `{{Infobox}}` and `{{Cite}}` templates and translate their parameters.

ok

The bad thing is that the templates in some languages are very basic compared to English

Polish version is also less rich in parameters.

The only available parameters in Polish `{{Format pliku infobox}}` template are: name, icon, graphic, graphic description, extensions, MIME, producer, development date, version, type, is open format, commons, www.

That's not bad, is it? Many people here are programmers after all, so anyone can improve the infobox template in their respective language. 😄

https://css-tricks.com/time-for-next-gen-codecs-to-dethrone-jpeg/

https://www.heise.de/news/JPEG-XL-Wie-der-neue-Grafikstandard-funktioniert-5993291.html

https://safeshadow.com/jpeg-xl-como-funciona-el-nuevo-estandar-de-graficos/

They're both translations of the same text.

Asked my colleagues in Israel to make a translation: https://he.wikipedia.org/wiki/JPEG_XL

https://tipsitaliani.altervista.org/jpeg-xl-wic-component/ https://tipsitaliani.altervista.org/how-is-the-codec-jxl/

Is novomesk here? Or any other native Slovak speaker? It would be great if you created the JPEG XL article on the Slovak Wikipedia. Translating from the Czech one should be damn easy…

OK, I added the Authors section to JPEG XL articles on the English, Czech and Esperanto Wikipedias. I hope there will be no war about who to add or remove. 🙂

it will be good to have a reference for that section; there is a pending merge request in the internal repo to do just that

once it gets in (and then out), we can link to it

I used the list of authors that was discussed here recently. So I couldn't use it as a reference because it's neither public nor "static" enough.

follow-up from <#794206170445119489>:

Regarding the Spanish Wikipedia article, I added .jxl redirect.

The thing with easily adding links from many articles to JPEG XL is that this Wikipedia doesn't have the template https://en.wikipedia.org/wiki/Template:Compression_formats

Anyone here speaking Spanish, ready to translate it? 🙂

I suppose firefox can be moved from proposed support to unofficial support?

Or is it too early for that?

I would move it as soon as someone tests jxl in Firefox Nightly.

Makes sense

why this page is needed in spanish?

or in every language?

the Spanish article wasn't reviewed by anyone

only me, I did a translation of the italian to spanish

and a few edit like adding unofficial support

If such a template exists, it can be added to the end of many articles. And this will cause the JPEG XL article not being an orphan anymore.

do you edited the spanish article

i see new commit

with better language

Of course it's also useful to have individual links from other articles to JPEG XL.

is a native spanish speaker

?

or you?

I edited the Spanish article a while ago. But that was an edit that didn't require any knowledge of Spanish. (I used Google Translate for the edit summary.)

if you are slovak better not do

me i'm italian i created the spanish article for fun

is copied from what crixis wrote

Don't worry, I don't do "dangerous" edits.

What?! Anyone can edit in any language if they feel capable enough. Don't command me! That's unacceptable.

ok sorry

i didn't know it worked in this way

to me italian future compatible apps don't need link

because anyway jpeg xl will be ready in a month

what?

all browsers will support it

no is wrong

maybe on nightly

but on stable

2 months at least

no before july i think not

Future Compatible Applications Gimp image retouching program plug-in that includes libjxl. In beta on the Google Chrome web browser. Waiting for Firefox, Wordpress and Facebook. XnviewMP starting from 0.98.2 reads images but not those encoded by JPEG lossless. JPEG XL format implementation called (libjxl, which mainly contains an encoder, test decoder, see Gitlab). It is pending ISO standard approval. Open photos on Windows Explorer: Plug in on the Github site win thumb jxl, and mirillis WIC component jxl, for developers, this plugin is not affiliated with JPEG and Microsoft. Nomacs on Windows (photo viewer) with Qt plugin. KDE plugin on some updated linux distributions.

this is the text in italian i wrote translated in EN

i didn't included links

that sounds super optimistic

it will be years before web developers can assume that most people use browsers that supper jpg, i would think

what means supper

i don't think in the dictionary

as a verb

in an optimistic scenario, jxl is enabled by default in Chrome 93, which has feature freeze on June 18 and has its stable release on August 31

then of course there are still people who don't update, or don't update quickly, so add some more months for that

that's just Chrome though

for Safari there's no indication yet that they're even considering to add jxl support

Firefox is likely not going to be faster than Chrome to enable by default

same for Edge

so likely 6 months before we have better jxl

at the time it would be standardized

delusion

and then there's a long tail of devices and users that use some old browser and will not update

ah

how do you know that

if edge and chrome and firefox have automatic update and even opera

who are those people

people who use vivaldi for example

or there is more

or is from android 9.0 and up

moving there

sorry, that was i typo; i meant "support"

Chrome is a good step, since it has a significant market share

When chrome gets implemented webservers can do the thing where they serve jxl to chrome and jpeg/png to other browsers right?

Saving bandwidth on images for 50%+ of your users is good even if all of your users don't see those benefits

yes

We (cloudinary) currently serve jpeg 2000 or webp to safari, avif or webp to chrome, webp to firefox and edge, and jpeg only to ancient browsers, unknown clients, and cases where 420 subsampling is problematic so instead of webp we fallback to jpeg.

When jxl becomes available, we'll do that, of course.

We recently retired sending jpeg XR (wdp) to IE and Edge, because 1) it's not such a great codec and 2) Edge has webp now and IE is slowly fading away.

https://http203.libsyn.com/when-the-hype-train-turns-out-to-be-a-bus-replacement-service

Haven't had the chance yet to listen to it all, but I did get to the point where you're saying jxl is getting hyped too much and people are expecting it to do things it cannot do (or not yet), which I think is a fair point.

My comparison blogpost not being completely objective is also a fair point, though I did make an attempt at making it a fair comparison.

What kind of quality is desirable as a "web quality" is a good question. I think it depends a lot on the use case. If it's a stock photo just to decorate what would otherwise be boring text, then sure, you can go low-fidelity as long as appeal is OK. If it's a product shoot of some item you're selling, and the texture of the material and the correct color reproduction are important (if you want to maximize satisfied customers that don't return items because they got something that didn't match their expectations), then fidelity will matter more.

Besides what would be desirable, there is also the aspect of what is practical. Manually selecting encode settings is something you can maybe do for the hero image on your landing page, but it is not something you can do at scale. Going down into low fidelity without manual QA will almost certainly lead to cases where the image is ruined. Erring on the side of "bytes were wasted" is probably still a better idea than erring on the side of "images were ruined", in most cases.

<@!228116142185512960> <@!710762823986446367> fair point also about me just giving stars in the comparison table instead of giving actual hard numbers. Main reason for that was to keep it simple, but that's a bad excuse (could have put numbers on a separate page and link to those, or something). We should absolutely produce some actual numbers to back up speed claims.

Compression claims are a bit harder to back up with uncontroversial data

<@794205442175402004> I hope none of that came across badly. Although that comparison chart made me pull a face, I'm still really excited about JXL. Once it's in Canary, I'll write a post showing off the progressive rendering in particular. I'd also like to compare it favourably to some cases where AVIF struggles (eg the Squoosh Red Panda image)

I think the comparison chart is quite accurate and fair, but I totally agree that it needs to be backed up with benchmark results (ideally performed by more neutral people than me, because I can imagine that after working on jxl for a couple of years I might be a bit biased 😅 )

And things are also not static btw: encoders/decoders can get faster/better

<@795684063032901642> <@768090355546587137> any idea when we can start to try progressively decoding jxl in canary?

well, ideally before the M92 branch cut 😛

what <@!179701849576833024> said, working on it...

is animation also being worked on, or not yet?

(I don't really believe in still image codecs doing animation, that's better handled by video codecs, but for animated jxl art it would be fun 😜 )

We are working on it, but I cannot promise anything in terms of chrome Milestones yet..

I don't think it's urgent, but it would be good to have animation supported before enable-jxl gets enabled by default, otherwise it becomes unclear if `Accept: image/jxl` means animated jxl will be OK or not. (breaking things when non-default flags are set is one thing, breaking them on default browsers is something else)

yes

I'd actually think of animation support as more important feature to get working sooner. Current ecosystem is heavily lacking support for them, and having at least one working viewer could help that, maybe.

Though it's kinda the same with progressive decoding and available viewers, I guess, so that may be moot point.

Though for local viewers it probably makes more sense to just decode it whole. Partial/lower res decode feature could be helpful too for viewing large images but I don't think that's going to happen soon.

I think the value jxl can bring to the web is more in progressive still than in animation, but of course not doing progressive decode is less "wrong" than not animating animations.

<@!260412131034267649> To be clear: progressive decoding is not the same as partial decoding; it just means that _while_ downloading the *full* image, the decodable parts are shown before the full download is complete.

So it's not an observable property for the website, or related to a feature of the file format. Doing it later means just slightly worse user experience, but it doesn't mean certain images will lack features (contrary to things like transparency, animation support, HDR, ...).

For local viewers decode speed should be fast enough to skip progressive steps except maybe for really huge images (where the DC is enough to fill the screen if you don't zoom in). Progressive is useful for showing thumbnails though (whole folder of jxl images)

yeah, I didn't imply it was the same. but getting lower version even if whole file is ready is useful for cases where images are really large and you gonna display it over 2 times lower resolution. it's also useful for faster thumbnailing (I think vips devs mentioned that).

Ok, sorry, just making sure. I've seen people make that mistake before.

I just included them both as it's 2 features what image viewers could benefit from for reducing memory usage

For making a 300x200 thumbnail from a 12 megapixel photo, just decoding the DC only would indeed be a good idea

it's just that I'd like to start playing with jxl for my serverside things, but lack of animation means that I'll need to re-examine whether it works okay when animation support lands, because pretty much nothing supports that part right now (pretty sure imagemagick doesn't), and there are no viewers too, it's kinda somewhat irritating that it's so neglected. but yeah I do agree that progressive jxl will bring more value in the end, and will probably be more important for bigger adopters too (like fb, etc)

Right, but progressive decoding can just land later (after browsers start enabling jpeg-xl support by default). With animation that's dangerous as people may settle on the assumption that jpeg-xl animation isn't expected to work.

Yeah, that's my main fear

Exactly this kind of thing happened for ogg opus stream chaining support. Right now chrome still breaks when they encounter that

Well, that's kinda obscure feature and I guess clients just neglected it, so may be not quite analogue

And that's exactly why I think that animations first, progressive a bit later. Lack of progressive decoding doesn't break the standard, lack of animation, though, does.

Of course, everything depends on dev cycles and priorities.

HDR, animation and progressive rendering are all priorities to get working properly.

Which would be the simplest one to implement and which one the hardest?

And by the way can we move to <#794206170445119489>, please? Gentle reminder that we're in <#822105409312653333>....

We're talking about those features being available in the Chrome integration right, not in the jxl decoding library?

Yes

The decode api already has that functionality

Interaction with how chrome does things is probably not so trivial though

https://www.linux-magazin.de/news/kaos-2021-04-bringt-viele-aenderungen-und-updates/

https://askubuntu.com/questions/1332041/which-apps-support-to-open-and-convert-jpeg-xl-jxl-pictures

https://twitter.com/addyosmani/status/1387431906359185408?s=19

Chapter 19 of the book is on jxl

https://mypornvid.fun/videos/12/lqi5U6dxeZU/xl-jpg/next-gen-image-format-jpeg-xl wtf why do people upload my talk there?

consider it a compliment

haha

~~maybe fabian did it~~

>people id say it was bots

because it included "jpeg" or something

🤣

anybody here has enough reputation/an account to say that plugins are available for qt and gtk viewers?

🙈

Maybe because you mention pik fuif.

~~Probably~~

> Maybe they will start converting their NSFW images to JPEG XL... Fabian has already tried <:kekw:808717074305122316>

Well we know how VHS vs Betamax was decided

I've got a question... how did you even know that it was uploaded here? <:Thonk:805904896879493180>

High fidelity nsfw jxl images - 😝

I googled "jpeg xl" to see if anyone wrote about it

i don't trust you <:HaDog:805390049033191445>(joke)

https://blobfolio.com/2021/jpeg-xl/

What kind of comparison is that? <:WhatThe:806133036059197491>

I wonder if this person understands that lossy image compression can obtain various size/quality trade-offs.

This tells nothing about the settings they used

``Its encoding speeds are faster than AVIF's, except for images with dimensions exceeding a couple thousand pixels — at which point performance drops off a cliff — but it is much slower than WebP.``

OK WUT

Is he serious? LMAO, threading becomes better at higher resolution.

What settings are they using even

To compare formats you need them to be encoded with similar psychovisual parameters (and even then it's usually still apples to oranges)

They criticize it for not being able to encode this image better than PNG

Maybe this is true

But maybe they used vardct instead of modular <:YEP:808828808127971399>

We'll never know because they don't publish their parameters <:ReeCat:806087208678588437>

PNG: 29.3 KiB

JXL: 25.7 KiB <:Thonk:805904896879493180>

They use their refract encoder

https://github.com/Blobfolio/refract

Which instead of constant quality seems to ask the user repeatedly if an encoded image meets their visual standards

Maybe this refract thing is single threaded

Don't criticize a format if you're not using the reference encoder<:NotLikeThis:805132742819053610>

Manually? Hm, but what where they aiming for then? The point where artifacts are not annoying or the point where fidelity is high?

I can believe that with avif they can go lower if it's mostly the appeal they're looking for, not fidelity

Idk it's just the subjective preference of whoever is using the application

Also I assume their app was ONLY using lossy vardct

Likely

And avif probably might beat vardct at lower rates

Like with the peach tree photo

From: https://discord.com/channels/794206087879852103/805176455658733570/837717369114722394

Oh they do -s 9

That is slow indeed

maybe i should start converting png at mozjpeg quality 100

to see estimate quality in xnview

and even webp

then i separate with a program

and i execute batch scripts

this is the faster way

avoid modular and those joke

and not wait ewout until it integrates jpg

or xnview until fixes 12 bit

<@!416586441058025472> yes

> Like AVIF, it aims to tackle everything AVIF tackles everything? Try progressive mode then <:kekw:808717074305122316>

-q 73.87 -s 9 -Y 8 -X 5.62 -P 7

"On the whole, JPEG XL is a disappointment. It offers superior compression to the (now 15-year-old) WebP format, but only sometimes, and offers superior encoding speed to AVIF, but again, only sometimes"

i'm tried this

Guys, please don't interrupt Fabian's walls of text!

I haven't seen any image yet where jxl isn't better than webp across the quality spectrum, in both objective and subjective experiments. I really wonder how he came to that conclusion...

And encode speed: default speed (or even -s 6) is very close to the slower settings in lossy compression performance (for lossless things are different). It's not a very fair comparison to just look at one encode speed setting (the slowest one) and conclude from that that AVIF encoding is (sometimes) faster.

Oh well

People are going to do silly comparisons and draw big conclusions from it, cannot really avoid that...

🤔

<:Thonk:805904896879493180>

can wp2 do palette

-q 94,6 -X 22.4 -Y 38 -I 0.68 -s 3 --palette --effort 2 -q 21.921 -s 5 -epf=1 --noise=0 --dots=1 --gaborish=0 --patches=0

like i want to do that settings

obviously q 100 - 21,921 i mean

Tortoise probably has the most not-yet-parallelized stuff. Also, it hasn't gotten as much attention as faster speeds. It wouldn't surprise me if in some cases it is actually worse than kitten.

palette effort 2 with wp2 does it work

i'm finding the settings

Yes, I have not compared the latest builds, but `-s 9` is often worse than the default speed

can wp2 do palette

i want to palette at q 95 q 100 with wp2

<#822105409312653333>

can you help me

<#805176455658733570>

I guess the speed comparison isn't quite fair if JXL is used for 8 iterations compared to 6 for AVIF and WebP.

The guy also didn't limit the thread count for CAVIF.

https://blobfolio.com/2021/fussing-with-images/

**How are things now:** > - If the source image is a (true) vector, save it as an SVG. > - If the image requires animation, save it as a GIF, unless it looks terrible reduced to 256 colors, in which case you actually need to make a *video*, not an *image*. Wrong article! Haha. > - If the image is a photograph, save it as a JPEG, unless it contains transparent regions, in which case you have to use PNG. > - Most everything else can be a PNG, though it is often worth comparing the PNG against a JPEG saved with chroma-subsampling disabled (to help preserve the colors). For images with more than 256 colors, it is often a toss-up as to which format can record the same data in the fewest bytes.

use PNG for transparency?

**How things *(hopefully)* will be:** > - If the source image is a (true) vector, save it as an SVG. > - If the image requires animation, save it as a JPEG XL, unless it's hard-to-compress live action, in which case you actually need to make a *video*, not an *image*. Wrong article! Haha. > - Everything else should be a JPEG XL.

And about the article, as far as I understood the goal to get the minimum possible size when the image does not look ugly, without comparing with the original, then yes, AVIF will often be a winner

I think animation is in 95% of the cases best handled by a video codec. I wish all browsers would just play video in an img tag (muted and autolooped).

Does the tool let you compare with the original or does it just show the compressed image?

From what I see it only generates the temporary file. You have to open it from the filesystem on your own.

I have not tried the tool, but if the author got these conclusions, then most likely only the encoded image is shown (or maybe only non-photographic content was compared, where AVIF is also strong in preserving lines and edges)

Either way, it depends a lot on how far you want to go in destroying an image to save bandwidth. If you want to go as far as possible, then avif will often let you go further than jxl before the artifacts become really problematic.

In practice, only very small websites can do image optimization manually where a human decides how far to go on each individual image

Operationally you need something that can be automated and that doesn't mess things up

Flirting with the "as small as possible" line is risky if there is no human to check the results and override things when needed.

Some of your colleagues work with the Chrome guys, why not try to persuade them of this idea?

Safari plays mp4 (h264) in an img tag. Chrome plays av1 in an img tag (if you wrap it in an avif container).

It would be nicer if they would all just play whatever they can decode. Or if at least there is overlap between the sets of supported video codecs in an img tag.

Also, I often see people use `-s 9` for VarDCT, perhaps while this speed does not give a guaranteed advantage and is not tuned, perhaps it is worthwhile to temporarily make `-s 9` equal to something like `-s 8`? And enable it when it will be more refined or only with some additional keys?

For AVIF encoders, the slowest speed usually always gives the best result (although perhaps not worth the cost of speed), as well as for modular JXL

Yes, maybe that's a good idea

In general, default speed is usually default for a good reason :)

"WebP, based on the VPN video codec"

Dang I never knew VPN was a video codec <:kekw:808717074305122316>

he meant vp number

If it means losing the ability to stop looping from the context menu, like you can for looping <video> in Chrome, then I am strongly against this. The best part about people moving from animated <img> to <video> is that it is no longer necessary to Inspect and delete the <img> from the DOM to stop the looping.

maybe we could emit a warning if you use -s 8 and -s 9 in vardct...

This is mainly for when needed to get the best possible quality/efficiency, even for comparisons, e.g. AVIF encoders (Aom/Rav1e) give a noticeable boost at the slowest speed compared to the default, but with JXL VarDCT it is not always noticeable or quality may be even worse, with much slower encoding

definitely a *lot* slower - I haven't tried 8 or 9 for a while, but IIRC they're at least 10x slower, no?

Something like that, although I have not tried the latest builds, maybe there were some changes

But when I was comparing, -s 8 still made sense to use, especially if needed more accurate size and quality was at least comparable to -s 7, but for -s 9 I did not notice any images where quality was better and in some it was worse, so it was pointless to use it For AVIF if I want maximum quality and when time is not important I also use the slowest speed, because I have not seen images where the quality is worse (maybe it is not always noticeably better, but at least not worse than the faster speeds)

From what I've noticed when testing photographic images with lossy, the gain from s7 to s8 and s9 is subtle, but once you see the difference, you will always notice it since it doesn't seem to increase efficiency much, but performs a lot more psycho-visual optimizations from which the image benefits a lot from.

Combined with noise synthesis, JPEG-XL becomes a very strong opponent for photographic/realistic types of images even low bpp.

Really, lossy/losslessness isn't a property of a file format, but of the encoder. Of course, a file format can be more or less appropriate for one or the other.

But any format can always be targetted by a lossy encoder... just throw away information.

Wait what?

Are you talking about reducing colors?

Or does png have an actual lossy algo?

PNG does 'support' lossy in the same sense that FLIF 'supports' lossy: it has no coding tools for it but you can do encoder preprocessing to get more compression.

PNG and FLIF cannot compete with actual lossy codecs though

I suspect lossy recompression glancing at the code

but to encode ex isn't doable

because you can't

look at every image

so in that case there are more efficient methods

that i described and added to the jpeg xl beginner guide

in the not tested paragraph

it needs a program that does test

and runs measures

and i don't even know how to batch encode in wp2 01052021

and how to automate png without xnview command but with cmd windows 7

so i'm starting bad

in theory a GUI would be better

but i would waste the time

Default cjxl (or say cjxl -d 2) is exactly meant to not need to manually select encode settings.

With the old jpeg (and webp/avif) you cannot just "set it and forget it": if you set it to high quality it will often waste bytes and if you set it to a lower quality some images will have problematic artifacts.

Default cjxl is change? i remember is cjxl -d 1.0 -s 7

Yes that's the default (on png input)

> Its compression capabilities are comparable to WebP's overall.

what

no

how do you even reach a conclusion like that.

(impersonal you, I know you didn’t write the article)

"JPEG XL, the New Image Format Nobody Expected but are Pleased to See" Fixed.

> *Like AVIF, it aims to tackle everything and, like AVIF, it manages to do so with mixed success.* Same way they came to that conclusion. The AVIF backers constantly say that it is not meant to be a GIF, PNG, and JPEG replacement. They seem almost completely uninterested in lossless. It's primary focus is on low bit images.

avif does low bit surprisingly well

jxl does everything else surprisingly well with few exceptions

I agree, but I feel there are ethical caveats to it. A couple that immediately come to mind is skin appearing to be Photoshopped, and artists that spend hours adding fine detail into their work having it wiped away might not be happy with the format.

That's the same with almost all lossy formats right?

JXL is the closest to the current JPEG in terms of appearance and features and I think that is going to go a long way with getting the general public onboard - they are used to JPEG so they will pass that familiarity on to JXL.

For anything that needs great detail people are probably using png

At extreme low bit, yes. But even at moderately low you can see through the artifacts that there is some sort of detail there, AVIF can basically wipe any hint that there was fine detail away in order to save on the bit budget.

And modular improves a lot on PNG on larger photos

When tuned though, AVIF becomes a lot better than you think at mid-high bpp. It doesn't become black and white anymore, which is interesting.

On the lossless end, the AVIF devs have little interest (for now). I even see some lossless AVIF that can be 10x as large as other formats.

Problem is, I doubt many companies are going to risk those caveats on the chance it will get better in the future.

Of course, I still do believe JPEG-XL is the better image format by a big margin.

It's also rather early days for the JXL standard 😛

I still stick to my original prediction: Video sites like YouTube, Vimeo, etc. will use AVIF at least for their thumbnails as they switch to AV1. Some smaller sites and bloggers that are fans of it will use it to. The vast majority of sites will switch to JXL.

WebP2 is really up in the air in terms of adoption. If it has some really good sizes and features it could gain some ground, but as of right now I see it as in limbo.

It is still unclear to what extent we are talking about inherent properties of the avif/jxl codecs, and to what extent we are talking about properties of the currently available encoders.

It is probably possible to make a high-fidelity avif encoder, or to make a jxl encoder that smooths out the detail and gets high appeal at very low bitrates.

I do think jxl has better coding tools for high-fidelity and av1 has better coding tools for low-bitrate high-appeal, but it's also a question of encoder developer focus.

I agree that low-bitrate high-appeal compression can be an ethical problem. Back when I presented my fuif proposal to the JPEG committee, I used to talk about "honest" vs "deceptive" compression artifacts (fidelity vs appeal is a more neutral way to frame it). If an image is overcompressed but it is hard to tell it is overcompressed, many will say that that's great and means the codec did a good job, but I think it is important to understand the risks and ethical problems that such deceptions can lead to.

Someone commented on the JPEG XL talk page in the English Wikipedia about the "Proposed support" section (https://en.wikipedia.org/wiki/Talk:JPEG_XL). And removed IrfanView from that section (https://en.wikipedia.org/w/?title=JPEG_XL&diff=1021775538&oldid=1021752414&diffmode=source). Based on his/her reasonable arguments, I would agree to remove the section from the article (in all languages where it is included). No other article in the English Wikipedia has that section. What do you think, guys?

I agree. I wonder why firefox and chrome are in "unofficial support" section though? Seems to be pretty official when intent to prototype gets posted, but not quite "support" yet

"unofficial support" is not the right wording, I suppose. It's more like "preliminary support" or something.

done the English one

The flags in Chrome are "Experiments" or "Experimental Features". Jpeg XL in Firefox about:support is under "Experimental Features". So, it should probably be called "Experimental Support".

Both "preliminary" and "experimental" sound good to me.

I also updated the Czech and Esperanto articles.

The spanish and italian are completely edited by me

Me i wrote the support

I think They are unofficial

And I saw in en someone marked as testing

So let keep things how they are

Do Not Spam your software

Because I got removed

I do Not remember if i edited english

I think Not

The webp arricle has too authors and no one has made a significant contribution looks like written by random annoying people

One Google author should Clean it

Unless it is explicitly prohibited, I don't think it is something wrong, since it is a translation of an open article with a link to the source and authorship

> I think storage space doesn't matter - codec efficiency and compatibility is the most important. 🤔 but if storage space doesn't matter, why does efficiency matter?

Might 'efficiency' refer to 'speed' (relative to sane density outcomes)?

I don't know, actually. As far as I am concerned, it's CC-BY or something, but I doubt Cloudinary has a specific license for stuff on its blog. Anyway I don't mind (and even like it) if people translate it or do other derived things with it if they link to the original.

Quite impressive that they even went through the trouble of translating that 😅

Well as far as I am concerned. But the blog is owned by Cloudinary so I have to check with them.

(esp since I was not the only person who worked on that article)

wikipedia can cite sources that aren't under permissive licenses tho right?

they cite academic journals and shit that you need uni credentials to access

you can cite anything

there might be an issue tho since that blog probably counts as original research which iirc wikipedia doesn't like

It's not even research, it's just my opinion, tbh

http://jpegxl.info/

updates welcome via pull requests to https://github.com/libjxl/libjxl.github.io

(both improvements in content and in style are welcome - for now I just put my personal page there with some minimal changes)

might take a while before the DNS records propagate, I only registered it today

we might be able to do something like that taking advantage of the Chrome build system

jpegxl.info links to jpeg.org/jpegxl saying that one is the official website

jpeg.org is the official website of the JPEG committee

jpegxl.info is the libjxl home page which contains info on JPEG XL but it's not maintained by the JPEG committee

just collecting info in a way that is easier to update and where we can link to things like browser tracking bugs, third-party integrations, blog posts, benchmark results and whatever without needing it to be formally approved/endorsed by the JPEG committee

(because updating jpeg.org/jpegxl basically takes up to 3 months and needs agreement of the committee)

no large download buttons please, that has bad connotations for me 🙂

Not large but easy to find?

easy to find makes sense - but probably need to be a bit sure that it's a trusted build (and also not a build that does no SIMD at all or something like that)

Need be a "official" build

in the end people asking to download cjxl/djxl should become as rare as people asking to download binary builds of libjpeg-turbo

probably better to point to viewers / editors that support jxl than to point to binary builds of cjxl/djxl

but for now it may be convenient to also point to cjxl/djxl builds

Legit

An easy to find tool list

And a visual benchmark?

Vs mozjpg

Easy to read yeah

Why no gitlab.io for website

plan is to move the repo too 😛

Why?

it's easier to deal with external contributions on github

No offense, If compare jpeg xl and libjpeg, I already find a vardct quality issue for non-photographic image, but i not sure this is a issue or expected result. I posted some data on gitlab.

we'll likely mirror on gitlab but take pull requests only on github

it's an area where encoder improvements are likely possible, but that's a nontrivial thing to do (i.e. it will take time and effort, and for now there are still a lot of other things to work on to improve libjxl)

I understand improve encoder is a difficult thing, and very grateful jpeg xl dev create this encoder, just really sad still can't use this amazing encoder on my use case(find this issue on January).

well you can use lossless for now, I suppose?

jpeg xl lossless is good, but i want more compression to my image, like webp near-lossless 40~60.

what is missing in the current encoder for your use case?

Have you tried `-m --lossy_palette --palette 0 -P 0`?

We have several ways to do good near-lossless, but most of it is not implemented yet or not very well

Compare jxl and libjpeg or avif, Can't keep good quality non-photographic image(drawing) on high or medium quantizer(target distance), like d 1.0, 1.45 and 1.9, d 0.5 have some improve on new version.

I already tried lossy palette, get some alpha channel issue. and find this issue https://gitlab.com/wg1/jpeg-xl/-/issues/221

Why has the main repo been put on GitLab in the first place?

because it had to be/have a private repo under an ISO account and gitlab offered free options for that at the time

Free private repos on GitLab but not on GitHub?

For paid users

you need a paid account on github for private repos

Not anymore

I think you do for Gitlab but Github dropped the pay for private a while back

There is a 3 collaborate max though

yep, but when we created the jxl repo it was entirely pay only

Anyway, we don't need private anymore

I think "good quality" this word might can't correct explanation this issue, cjxl d 1.0, 1.45, 1.9 on specific drawing image, can see some tiny white noise issue, that issue is very conspicuous for psychovisual, (For now only jxl d0.5 can reduce this issue), I understand dct lossy will create some artifacts on lower quantizer, jpeg q90 also have some details lost, but artifacts not look so bad. I share this issue to Scope, and this is his comment, For the jxl d1.0 image, I see some red areas in the hair, (very small color areas spread out and shift the other colors).

How does d0.7 or something look?

still have this issue, only d 0.5 can reduce.

maybe i used wrong image type on jpeg xl vardct?

Could also be the XYB transform is not ideal for this type of content...

https://www.deskmodder.de/blog/2021/05/09/jpeg-xl-als-neues-bildformat-im-browser-aktivieren-chrome-edge-firefox/

Seems that Germans write a lot about jxl. They just keep omitting Wikipedia… 🙂

Why does it say "nearly lossless" is possible? I thought JXL can be 100% lossless

but JXL can be mathematically lossless, right?

Yep

so the article is wrong

Jpeg xl has better context than other formats

Like when You see an iphone or a rapper it dont look Very artificial But i guess sometimes even svt av1 that is a video codec can do better

Yes, not only is "nearly lossless" wrong, the resolution also doesn't have anything to do with actual compression

i wrote a comment on that

That means whos writing the article

In jpeg trascode yes, but not in vardct and modular mode

Disinformation on jpegxl is strong

I don't think it's conscious disinformation, it's probably just uninformed people on the internet saying stuff

which might mean the problem is rather "information on jpegxl is weak" 😅

Misinformation is the word here

Disinformation is strategic, Misinformation can be unintentional

Any news from apple or adobe for adoption?

are there any myths that need debunking?

besides random people on the internet saying wrong stuff

(cannot really write a blog post to correct each of those)

but maybe there are things that come back regularly and that could/should be debunked

JXL is not big enough to actually have myths lol

this is an image codec no average person has heard about, not something like a pandemic where you have plenty of myths :p

I guess a German Wikipedia entry should be enough. ;)

Any German Wikipedians here? 🙂

https://de.wikipedia.org/wiki/JPEG_XL <@!792428046497611796> <@456226577798135808>

idk if i fucked up the references or not lol

missing most of the technical stuff so far

"sowohl verlustbehaftete and verlustbehaftete Komprimierung unterstützt" Double holds better! 😄

oh god

i should focus more on this hahaha

fixed

Also, is "and" a German word? 😜

...i rushed this

yeah but i can't do manual formatting there idk

it's a template field

Yeah, I had to add a bit of new links to the Polish article, it was a bit exhausting to find some things...

Hahaha, great joke :D

The site is still unreachable after several days. Tested with various browsers, devices and ISPs. What's going on there? 😢

you're right. doesn't work for me now either. let me check registrar

looks like somehow I managed to delete the `A` record

<@!532010383041363969> can you check for errors? https://en.wikipedia.org/wiki/Draft:Jyrki_Alakuijala

The solution here would be to change the infobox template so as it takes the data from Wikidata.

can you try if it works now? I updated the dns settings, for me it works now (but it might take time to percolate)

Not yet. But I'll keep trying.

so I guess libjxl.github.io also doesn't work, because it does a redirect?

added a COI box - obviously I've collaborated with jyrki so that is a COI, I suppose

I see it more as a navigation tool, where e.g. someone can visit the JPEG XL page, and click on Jyrki's name to see what other things Jyrki has worked on.

OK, it works now here as well.

nice

if someone has suggestions for style / content, feel free to do stuff and make a pull request. I don't currently have time for it.

https://github.com/libjxl/libjxl.github.io

What are the plans with sneyers.info/jxl? It currently redirects to the new site after 5 seconds. And the 2 pages are almost identical. That's quite confusing.

If the goal is to "forget" the old URL, the easiest solution IMHO woud be to redirect immediately and (to try) to replace the old URL with the new one everywhere we can (Wikipedia, Wikidata, sneyers.info, …).

But yeah, making a new site for the existing content was a good idea. 👍 The author-independent URL looks more professionally.

Yes, it's just that redirecting immediately can be annoying because it breaks the "back" button, right?

(that's the only reason I set it to 5 seconds)

Before we replace the url everywhere, I do want to get some input to make the content also more author-independent, not just the url 🙂

(it's too many links to my own blog posts and stuff, it needs more 'non-jon-stuff')

I wouldn't really recommend wasm polyfilling for actual normal use - better to do `<picture>` with fallback, or even better look at the `Accept` header and serve jxl/avif/webp/jpeg depending on what it says (or use Cloudinary or some other service to implement that for you - not sure if there's anyone except Cloudinary that already supports jxl right now though)

wasm decoding of images is bad for performance not just because decoding is slower than native, but mostly because you won't get image prefetching etc

(it might be an option for below-the-fold images though, but still not an ideal option imo)

Instead of the redirect inside <head></head>, it would be better to do https://en.wikipedia.org/wiki/HTTP_301

https://www.ghacks.net/2021/05/11/find-out-if-your-browser-supports-the-new-image-format-jpeg-xl/

serving jxl isn't enabled by default yet, I'll ask them to enable it on the cloudinary homepage 🙂

might be a good idea, yes

should probably make it not break in middle

i think there was some tag or css thingie to make things non-breaking over lines

making css `hyphens: none` for that <code> block fixes that

It's not universal. Other unwanted line breaks can occur with other window widths.

added it 🙂 — it's quite a bit smaller than the PNG version too

curiously this only happens on firefox, not on chrome

Maybe <@!794205442175402004> has a heise.de account he is willing to share with access to his article, so that this could be linked to everywhere on the German wikipedia page.

I don't have a heise.de account

Damn, you really should have negotiated an account with full access when creating the article. :D

What do you, guys, think about the lead at jpegxl.info?

*Welcome to the libjxl home page. Libjxl is the official reference software for JPEG XL.*

Is the site meant to be more about the format? Or the library? Or both?

Both, but we have to be careful not to give the impression of being the official WG1 (JPEG) website, because that's not the case.

So it's a site about libjxl and about the format, but it is coming from the libjxl implementers, not from JPEG itself nor necessarily approved/endorsed by it.

The title of the page is JPEG XL. The content is also mainly about JPEG XL (and not so much about libjxl). So shouldn't the lead reflect that? 🙂

Yes, just have to be really careful that people do not get the impression that it is a site made by JPEG. Building websites with committee approval is a very slow and tedious process...

Would the word "unofficial" be suitable/accepted for the lead?