JPEG XL

The original document is from at least a year ago and parrots the community site's overstated marketing claims.

Agreed. From their about us section, that site appears to be some sort of marketing company.

I assume that this is the way to influence industry standards like PDF. The key people to convince here are probably not super technical but rather Product Manager type people who see things from a high-level functionality point of view and who are more used to speaking Marketese than factual no-nonsense technical language.

https://www.phoronix.com/news/Chrome-145-Released

Oh yes JPEG**-**XL I love that hyphen<:PepeHands:808829977608323112>

Doesn't even register anymore for me at this point 🤣

Uh > I don't say this often, but thank god for Apple. Bullied Google into supporting a useful codec instead of burying it because it wasn't their IP. > Apple pushed HEIC. Thank Firefox for JPEG-XL.

Hmm

Thank the PDF Association :v

Thank firefox? ...wat?

Thank Firefox for sure. If it's just Safari alone Chrome may or may not follow it, but with both Safari and Firefox Chrome will likely follow. I think people overestimated the impact of PDF on browser support, it definitely helps, but it's not like a decisive factor. We have JPEG 2000 in PDF for over 20 years

Yes, that was likely not the decisive factor, just another indication of "broader interest", just like DICOM and DNG adding jxl as a payload option were indications that regardless of browser support, the codec does have merits.

I wonder when JPEG XL will escape Nightly in Firefox

I was wondering why it wasn't working (in chrome), but it's still behind a flag

kinda wacky how the flag still exists and tries doing things in non-nightly despite only nightly having the decoder compiled into it

IIRC enabling the flag on non-nightly starts telling websites that you support JXL and then they all just fail to decode 🫤

it's so weird too because I think someone at Mozilla noticed this or half noticed it and then wrote down that the flag is just for telling websites you support JXL but not actually supporting it

oh wait the page says both? idk if It did that before: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Experimental_features

I don't understand why JPEG XL is not under "behind a flag" while still being behind a flag

maybe it's because I'm part of the 'no JXL' group of the origin trial? is that how it works?

or...no

is it just enabled for certain hosts, then

still I feel like it's too early to allow sites to opt in to testing JXL support.. the origin trial wasn't even filed for that purpose

https://discord.com/channels/794206087879852103/803574970180829194/1466549189566795957

https://bugzilla.mozilla.org/show_bug.cgi?id=1922974

okay so the headline should be "JPEG XL support lands in Chrome not in section "behind a flag" while behind a flag, in section "origin trial" while not part of an origin trial" <:KekDog:805390049033191445>

It's just the dev trial form is not filled, but the origin trial one is. Not reflecting the current state

https://discord.com/channels/794206087879852103/803574970180829194/1466549189566795957

https://www.debugbear.com/blog/jpeg-xl-image-format

> There is no question that the JXL format would offer improvements in image format compression and combine a lot of features from other image formats. But JXL does not offer any new features to web imagery. That is, although it may do what other images already do better, it does not offer anything that other image formats don’t.

I kind of beg to differ. Proper support for HDR and layered images, for example, are things jxl offers while jpeg, png, gif, webp cannot do it.

png is perfectly fine for hdr, no?

ignoring compression efficiency

Isn't HDR support one of the main reasons that AVIF is introduced? But I'd argue high bit depth, large dimension lossless counts as a new feature

That's a pretty big thing to ignore for images on the web...

well yes, but i thought we're just talking about individual features and i'd count efficiency as a separate thing

And yes, avif can do HDR too, and so can jpeg 2000 and jpeg XR, and even the old jpeg in 12 bit mode. So not really something new that jxl brings. But compared to the common web formats (de facto jpeg, png, gif, and maybe webp), it's new.

i guess you could argue that combining pretty much every feature from other formats is a feature in and of itself

yes

Lossy HDR PNG, hmmm....

~~Indexed HDR PNG~~

If efficiency isn't an issue, you don't need image formats at all: just embed a huge Javascript thing that draws hardcoded pixels on an image canvas (SDR or HDR)

Recently I saw a friend using a 3KB SVG file to add noise to their website background

If I had a HDR display, I'd give that a shot with djxl decoding to 1-bit blue noise dithering

you don't have a phone that can display hdr images either?

Just off the top of my head, JPEG transcoding, float data, layers and (efficient) progressive loading are pretty big points

It uses a proprietary API by Huawei, so only the built-in video player and YouTube enable HDR. Annoyingly even though YouTube works, Chrome doesn't, so images either don't load properly or tonemap to SDR

with 1-bit, you run into the problems described by https://sjeng.org/ftp/SACD.pdf

In this case it's 1-bit per channel, so I think it should be fine... Though, even 3bpc (usually) still fits within 256 colors for indexed PNG

wait, so you don't even get hdr in normal exoplayer apps?

That's the first time I've heard the word exoplayer

it's the library that most apps use for media playback, by google

like most video player apps are just wrappers around that basically

hdr only working for video playback is standard for older android versions, but it only working in specific apps certainly isn't, that's why i asked

Youtube, Google Photos and the built-in Huawei video player work. Chrome and FossifyGallery both don't

I did kinda doubt if it's 'real' HDR because the UI goes out of gamut and it doesn't look much different to SDR, but I did a youtube side-by-side with an iPhone last year and they matched

you could try this experimental mpv for android release with vulkan to see if you get hdr with that https://github.com/mpv-android/mpv-android/pull/596 to verify whether you get SDR or HDR you can do `adb shell dumpsys SurfaceFlinger` IIRC

Layers is also not a new one because AVIF supports it, yet I haven't seen any real world use case except AVIF uses it for pseudo progressive

Crashes/fails to open the file

what file are you trying to open? is it a video? mpv for android has sadly barely any support for images

This one https://discord.com/channels/794206087879852103/1065165415598272582/1231532484190146570

Hm, works on my phone

https://hacks.mozilla.org/2026/02/launching-interop-2026/

https://bsky.app/profile/henrihelvetica.bsky.social/post/3meyolf7r3k2y

Let me know if there's stuff I should mention. Besides that there's no dash in JPEG XL.

what sorts of discussion(s)/topics would be relevant (I'm unfamiliar with this ¿show? idk what types of stuff it covers)?

you should facetiously mention the hyphen they used in their tweet <:CatBlobPolice:805388337862279198>

OH I should have read further lol

nice

I wonder if the old timey Dutch police car is a coincidence or if they're conflating the Netherlands and Belgium

- the ressource consumption, energy cost and time to losslessly convert existing jpegs compared to doing the traditional 'full' conversions that are still possible (ie resized, edited, to another format). before jxl, lossless conversion from a lossy source normally triples filesize or requires doing a lossy conversion not even guaranteed to have a smaller filesize than original

a ghetto desktop cpu blitzes through conversions, a server's spare cycles could complete a job in 1000 less time than for full conversions to either jxl, avif or even webp

- competitive advantage for mobile, desktop and in-webview apps (that have ads) compared to browser versions (that have to work around adblocking in addons and browsers natively). your ad-enabled app loading faster than the site and your ads showing sooner/progressively

in the context of the stream would it make sense to describe a benefit of progressive decoding as being a safety net for poorly optimized images? because something I've realized is that getting better image formats does not stop people or sites from serving absolutely giant (in file size) images as main content but at least the progressive decoding makes the experience of interacting with such places/situations much less painful. Of course this isn't much of a concern for properly managed and optimized CDNs but outside of that it can make a noticeable difference

services and search engines could preload an incompletely loaded jxl instead of the full image. probably handiest for search engines, galleries and link previews/embeds

Guess examples from various fields Where it performs exceptionally well and where other alternatives might be worth considering For what kind of types of images the reference tools will probably get better in the future in terms of speed and compression (what has been spend time on, what not so much, the some WebP can still be smaller situation) Which file formats it can replace (almost) completely Maybe some words about getting small files and the math The patching stuff (e. g. for game tiles and character face expressions) If it you think older space-constrained systems (game consoles, mobile phones) could benefit from it (theoretically – if we could just put in support at the OS level – and practically, also considering the computing power) That DICOM really needed something new That other stuff can be included inside JXL files Also limits and things you would design different if you started from scratch That the header size is so small compared to other formats despite it features Layers, animations, etc. JXL art ofc. Some trivia, maybe largest files you came across so far and how much was saved by using JXL? Long-time supported platforms, e. g. Qt/GTK, platform-wide on the whole Apple ecosystem since _year_. And then mentioning it has been approved in the web interop and can be used with feature flags set in Chrome and Firefox Nightly, expecting default support soon.

games on pc and consoles need to be able to capture hdr screenshots and losslessly if possible. other than photos, probably second biggest source of hdr

Updating my slide deck to prepare for my live chat with Henri in a few hours. I'm quite impressed with the images generated directly in Google Slides nowadays...

for example

The carts are facing backwards, half the arrows point to nothing and the track is apparently exploding on the right, but I like steampunk so that's something

of course it's still obviously AI slop but for something like a slide deck this kind of stuff is pretty nice imo

Personally I'd avoid it if I can, just gives more ammo to people hating on the format

tho I find it funny that Chrome with JXL is in the light, but in the dark without <:KekDog:805390049033191445>

Both image are generated by GPT The best AIGC is no one notice "this is AIGC"

The rare two knob slider (second pic, second stage)

Good luck <@794205442175402004> !

It was a really great stream.

Thanks!

https://www.corewebvitals.io/pagespeed/jpeg-xl-core-web-vitals-support

https://www.imageguide.dev/guides/jpeg-xl-future-format/

> With only ~1% of file data downloaded, a usable full image preview appears. Glad to see my edit to jpegxl.info is already spreading

Quite a comprehensive article

Hmmm

Looks like they didn't update it either

so true

I recommend 25 bits per pixel for the best quality

On one hand, I guess that means they kept hitting 1 bpp for perceptually lossless, on the other hand that means they were always hitting 1 bpp...

we've got libjxl built into empty directory

the CDN they suggest, Sirv, doesn't even support JPEG XL from what I've found

they are *greatly* overselling libjxl's ability to preserve sharp edges for graphics/illustrations at the lower end of that quality range...

this article is definitely the best of the two 😄

the imageguide.dev one basically has to be AI slop, right?

if not AI, it's human slop

My gods finally someone used libavif <:BlobYay:806132268186861619>

First one is invalid cause no mention of libs used

Seen soo many jxl vs avif articles, stating libs/program is a minimum for me to even read it xD

scroll on the element for the actual build instructions

certainly looks "AI-assisted"

what is this thing even? "Saafs"? And even besides the nonsense of "Saafs", that combination of two fonts for the "a" is really sickening

new logo tech unlocked

Software as α service... but when you're annoyed because you wanted to install it locally.

aaaah

Software as a F*CKING 'service'

it really is becoming self aware

right? I actually stared at those letters for what felt like 10 seconds, confused, like I was missing something obvious. at no point in the past have I ever seen those two ways of writing the letter right next to each other, it felt like no part of my brain was equipped to process it

One is latin a and the other is greek alpha

nah, the one on the right is a pretty normal a, though more popular in handwriting than in fonts.

https://fosdem.org/2026/schedule/event/LJXYCF-vlc-ffmpeg-librairies-kyber-2026/

jpeg xl mentioned at 4:12

and at the very end on the last question

Oh hey, it's the cone hat

JPEG XL has the best marketing? that's an interesting take

imo if there's one thing the JPEG committee is not very good at, it's marketing 😅

It's basically what you put out + vocal users

It doesn't need more

~~Imagine how we got SIXEL in so many terminal emulators nowadays~~

considering the amount of slander avif gets from random internet users, jxl's marketing department is working overtime <:kekw:808717074305122316>

Sometimes the best doesn't mean the largest

WebP had the largest marketing ever

I never saw an Ad for WebP, just people complaining about it and Google serving it

Google's coercive tactics about webp are widely known. That can be called dark marketing.

it's honestly impressive given how suboptimal the lossy encoder is

we currently have desaturation, color bleeding and fringing even at high qualities maybe when we say JXL is the future, we're putting the emphasis on future <:KekDog:805390049033191445>

we don't have color banding though! and good lossless!

goes to show how sentiment can be a big part of reception i guess, it's not the fault of avif that the chrome devs rejected jxl (even if jxl's lossy quality isn't optimal for web use)

hopefully that happens soon, wouldn't want to wait until a jpegli like encoder is needed

oh yeah, I mean I deliberately try to avoid the Chrome-WebP-AVIF drama, it's so much hearsay, nothing is concrete and I don't enjoy talking about it

JXL is a part of JPEG, which have connections to various important entities. So while it's not marketing, it's not an indie project, either.

such is the nature of the internet unfortunately, and in this case it creates a problem that ultimately harms the majority of people (negative stigma around webp and avif, thus less use, thus resorting to jpeg, gif, and png thus leading to more data use and slower page loads)

And somehow we're still competitive

Lads really want off the jpeg/gif train <:KekDog:805390049033191445>

Ironically thanks to our PRs if the source image had banding, it gets dithered away at distance 1, so we actually have less banding at lower qualities

We roughly know *what's* broken and *how* to fix it, but lack the knowledge/time/expertise to actually do it. Desaturation is from the B quant table, color bleed/fringing is probably a mix of the quant tables and DCT block selection along with Gaborish drifting over time to be misalinged between the encoder and the decoder (Severely hurts generation loss)

while there is quite a lot of misinformation around the situation I do think it's very easy to point the finger at people involved with AVIF or "the AVIF team" considering the announcement of JXL's removal was in part coming from them against what seemed like the rest of the industry and when questioned as to why this was happening the follow up was benchmarking/test results directly labeled as from the "AVIF team" alongside the official web.dev blog posting articles written by people who work on libaom (one of which has absolutely baffling conclusions within it that don't even seem to make sense when comparing AVIF to AVIF/itself). While conspiratorial thinking can very much be bad and harmful I do think there is a opposite side of spectrum such as giving too much of the benefit of the doubt to things and not believing something unless confirmed without a shadow of a doubt. considering that it is a very common thing for people to have their decisions dictated or influenced by biases and the like at all levels of power. People at the end of the day have lots of various factors contributing to their actions/decisions such as the mentioned biases alongside just differing insight and skills in relation different things so it really isn't a stretch to say that a decision coming from withinside a sector of a company is likely to have been painted with one of the things mentioned above. As for *exact* line of thinking that lead to JXL originally getting removed from Chrome, we may never know exactly but it isn't really that hard to tie it to AVIF in some form or another whether it was a simple "why do we need another image format so soon when it seems like it performs on par with the latest existing one" or a more deviously cartoon villain "*our* format is superior therefore the existence of another shall not be allowed". Sorry if this message seems absolutely bonkers lol, It's just an attempt to get some of my thoughts out even if maybe not exactly expressed the best.

It's pretty obvious *something* was going on, between botched benchmarks with baffling results to refusing to answer emails from Jon about it

> JXL originally getting removed from Chrome, we may never know exactly Because Chrome team need to tell boss "how to save money", BD-rate can save money, user experience can't

a single youtube video view consumes more storage and bandwidth than 2000 adequately encoded images (one netflix movie? a month's worth of images viewed). images should be encoded more efficiently at all filesize ranges, not be given less bytes to work with than the year before

Yeah I notice that if the original image has banding, jxl un-bands it

lighthouse

I disagree strongly. User experience / image quality absolutely can save money. Bandwidth is much easier to measure but it's also usually not the main factor in any company's bottom line. In e-commerce and anything else that depends on prospective customers navigating pages and clicking something to perform some target action (typically "buying something"), getting a smoother UX (e.g. product pages that feel 'snappy' thanks to progressive loading) directly translates to better conversion rates. Image fidelity is directly related to return rates — people do return stuff bought online because the color isn't what they thought it would be, or because the texture of the textile looks and feels different from what they expected. A codec smoothing out some texture or slightly shifting colors can directly cause an increase in return rate, which is a bigger cost for e-commerce companies than bandwidth — transferring bytes is way cheaper than transferring physical products.

You are correct, but this is Google They control Chrome and YouTube Negative externality? Not on Google's financial sheet <:ugly:805106754668068868>

I do understand where you're coming from and how this situation formed. The internet generally dislikes corporate behavior and google being a big corporate company often has made decisions which the public disagreed with, couple with all the features JXL supports (with imo an improportional emphasis on jxl's progressive decode) has made the format seem like the future of the internet (doesn't help when presented as the next jpeg), and so the blocking of it whether warranted or not is going to cause controversy. Some other websites (including other corporations like Adobe) coming out in support of the format has caused the internet to rally around them in psuedo protest. My problem is that all of this came with throwing AVIF under the rug, even if "the avif team" presented incorrect benchmarks, if someone else would do the benchmarks themselves while they will see that JXL is a lot more competitive, AVIF is still better for low bpp images, which is a big part of the internet. Also doesn't help that down the line AVIF got the Image Quality tune massively improving its lossy quality making it more appealing but because internet stance rarely updates, people still think jxl is universally better than avif. Overall it's just an extremely unfortunate situation all around that ultimately harms most people ultimately painting any format by google (including webp retroactively) as bad, all of this pitting it as a AVIF Vs. JXL fight where there's space for only one of them impacting adoption of formats most appropriate for the situation tl;dr: both formats good, they don't have to fight

I will not go in details, but I can say I am _quite_ annoyed about how things have been handled internally in the whole discussion

but whatever, it's all in the past, no need to lose sleep on it now

judging by how often I turn away from YouTube to Twitch for stream VODs because YouTube compresses them to oblivion, I think quality is pretty important for YouTube as well. it's just that there often isn't a competing platform people can watch the videos on instead. VODs are an exception, because at least for a little while after the stream is over you can still watch them on Twitch

It is true that in general many decisions with far-stretching consequences are the result of relatively silly and random "office politics" rather than some kind of rational and democratic decision procedure. There are far worse ones than this particular example, e.g. if you consider the fossil fuel, weapons, or pharma industries, where much worse decisions are being made, in terms of impact on humanity. Although I guess there it's generally less "random office politics" that is the problem and more that they're being effective at optimizing for the wrong objective function.

Nonsense, they do have to have friendly sparring matches <:ChizuWink:857418269647700003>

As competition fosters innovation and prevents stagnation/complacency/enshitification

you know what kind of fighting i mean

Yea I know, why I said friendly xD

I think the <#805722506517807104> bot might be broken, I keep noticing new posts on the Reddit but nothing in the channel

https://www.reddit.com/r/jpegxl/comments/1rh8krn/in_january_a_google_dev_indicated_it_was_interest/

checked the bot status: > Reddit Feed has been disabled because of an API block from Reddit. You won't see it on the dashboard till there is a resolution from reddit on it.

Ah lovely

Oh hey, the video is finally listed again https://youtu.be/3t2wYYnLctU

https://bsky.app/profile/jakearchibald.com/post/3mg3gkhir622j unfortunate coverage

as usual, avif's superbad performance at lossless is handwaved away

afaik modular can be lossy too. most encoding workflows just dont expose more parameters to adjust than the base minimum (ie quality/distance and effort)

Or a hint that Firefox would be the last to adopt JXL

he tests lossy modular in the replies (but avif still wins)

AVIF is pretty good at screen content so I'm not surprised

although lossless simple screenshots always look much better

> My learning here is: You can throw pretty much anything at AVIF, whereas JPEG XL is more like WebP, in that you need to get a feeling for when to put it in its 'lossless' mode. or just use the appropriate quality setting instead of artificially targeting a size 10kB lower

Surely a 512kbps AAC will be better than a 200kbps FLAC of dialogue [Clueless](https://cdn.discordapp.com/emojis/1072229693685772380.webp?size=64&name=Clueless&lossless=true)

<@794205442175402004> Totally agree. The maturity of e-commerce needs JPEG XL to support PDP (product placement e-com pages) and reduce costly returns. Even if WebP or AVIF could be used on other content pages for marketing or editorial, the PDP product page is where the decision to buy or return is made, so quality is a top priority. WebP on PDP page is destroying product trust. I remember dark blue jeans stitched with bright, saturated orange thread being returned because the client didn't like the excessive color of the bright orange stitching. WebP halves the color saturation when colors are very thin against a dark background (due to WebP's 4x4 spatial prediction). JPEG XL doesn't do that, and that's vital for e-commerce brands on their PDP pages. <@594623456415449088> That being said, the JPEG XL page should include a more illustrative example of the benefits of JPEG XL's benefits for e-commerce color/detail trust on PDP e-commerce pages.

Obligatory 4:2:0 chroma subsampling (like in WebP) makes it impossible to achieve a high fidelity of fine colored details. But even without color: the smoothing caused by PSNR-optimizing encoders tends to just erase subtle textures, which is quite problematic when it's an image of some delicate textile. E-commerce already has the problem that customers cannot literally _feel_ the clothes, they have to rely on their eyes alone. But that requires high fidelity. When cashmere becomes plastic and you can't tell the difference between linen and polyester, the image just fails to convey crucial information.

Big yep. Jake's comment is very misleading, suggesting: 1. JXL is like WebP 2. Lossless is the only alternative if you don't reach avif size He doesn't actually believe this, he's manipulating the opinions of those less informed for reasons I could only speculate about.

(my speculations only really go as far as "not my team" fandom behavior)

He's comparing it to webp rather than avif and correctly noting that AVIF delivers an extraordinarily good result at low BPP and that JXL is not quite competitive there. His job isn't *quite* "figure out what is or isn't well optimized on a website", but it's pretty close, and this is the sort of thing I'd notice and tweet about if I were in his position. Had he been acting in bad faith here (and I think his mention of lossy modular would suggest he wasn't), IMO the post fine stands on its own.

His job is about making websites load and perform as quickly and as well as possible, promoting perfect image fidelity. Heck, the premise of the post is literally him arguing that people should accept some quality loss and drop lossless compression. It's okay to concede that AVIF genuinely does really well here.

> load and perform as quickly and as well as possible No progressive load, even no partial load <:FeelsAmazingMan:808826295768449054>

There really isn't a point to progressive or partial decode when your images are that small.

There really isn't a point to use advance format when your images are that small

They're that small *because of* advanced formats.

Getting the entire image, in that quality, to fit in a single HTTP/3 DATA frame is genuinely really cool. I envy that they have an encoder that can pull it off. I do not understand why this needs to be tribal / why someone needs to be accused of "manipulating the opinions of those less informed." It's a cool example. It'd be nice if JPEG XL could perform similarly.

people MUST use only ONE format, there's no room for debate

while i personally prefer if websites used avif for how small images can be, I wouldn't mind if the website also used progressive jxls, those can co-exist ANYTHING as long as it isnt gif or jpeg

if input size are small, the BD-rate advantage will be less if input size are big, the BD-rate advantage will be more, but output files are still big enough to justify progressive

What's the point of progressive if the entire image is sent in a single HTTP/3 data frame?

One HTTP/3 data frame is default 16 KB, enjoy your small image

I'm here because I enjoy small images, yeah.

https://ione15.com/sharex/test/screenshots/ someone made a small page to test prog. decoding and loading speed of different image sizes limit chrome to your desired download speed with cache disabled and you can compare the benefits

while not comprehensive, it does give a vague idea

(Aside: I'm sure it comes across that I'm concern trolling, but I really am here because of the fact that I like really small images. Most of my JXL-related time has been invested in writing my own lossy modular encoder [(older version shown here)](https://discord.com/channels/794206087879852103/824000991891554375/1441183512391585842) purely out of love for the challenge of making really small images. I hope people interpret my linking of that post (and defense of it) as genuine interest in low-BPP compression and not something more malicious.)

i dont think anyone was thinking you're concern trolling, you might be overthinking this

you can support both sides while still being in favor of avif for web, jxl can still fit other niches

Phew, thanks.

im in the exact same position, i would love if every website switched to avif, but wouldnt mind jxl

Isn't he in this sever?

the tweet op?

Yeah, Jake. Sorry, phone was lagging behind on messages

seems like it?

I think the point is the encoder should decide when to switch to lossy modular

There is a lot of room for encoder improvement in jxl. That particular image is 33kb as a lossless jxl, 43kb as lossless WebP, 61kb as lossless PNG and 110kb as lossless AVIF. Surely a smarter lossy jxl encoder could create something sensible in 10kb too, when using all available coding tools effectively.

I reckon near lossless webp would do a good job.

Lossy modular obliterates chroma currently. I have a branch with adjusted values, so might do better on that image. IIRC it was Gianni who brought the AV1-PSY non-photo detection heuristic to our attention, so at some point we should implement that into libjxl and pick DCT or Modular depending on photo or non-photo (mixed could use patches?)

do we have the original image somewhere? I wanted to try lossy VarDCT, but quality- rather than bitrate-driven, but all I could find was the AVIF version

I don't have the actual original, but I took a screenshot of the same page which should be quite close to the actual original

What command did you use for the lossless JXL encode? I have a feeling LZ77 only might do decently with/without patches

just -d 0 -e 10

> My learning here is: [...] JPEG XL is more like WebP, in that you need to get a feeling for when to put it in its 'lossless' mode. How can this not be a lie? You think he really believes JXL quality is only acceptable at the cited 36kB lossless cost?

You objectively do need to turn on modular to get good results at that bpp with libjxl here...?

Did he ever give the AVIF command? It was only a week ago the new encoder version came out that doesn't require half a dozen parameters

It's not like this is a world-ending catastrophe but I think "best results come from using modular, which you need to know to do in advance" is perfectly honest. His use of "lossless" is bad verbiage, but he puts it in quotes for a reason.

Lossless uses Modular, but Modular doesn't have to be lossless (the same way Lossy PNG exists)

Right, that's why I said it's bad verbiage and pointed to the quotes.

That lossy modular result isn't actually acceptable, he says it's "pretty bad". I don't believe he's targeting some bpp anyway, he's targeting some level of visual distortion. The claim that he learned lossy modular is sometimes necessary based on his examples doesn't make sense.

It's not shown that lossy modular performs better than default lossy at similar visual distortion to the AVIF.

Yeah, that's what I mentioned

at the very least, one aspect where JXL is not like WebP is that the reference decoder doesn’t print only the first character of filenames ```console $ dwebp interop2025_screenshot.webp -o interop2025_screenshot.png Decoded i. Dimensions: 980 x 667 . Format: lossless. Now saving... Saved file i ```

wat

Is that a libwebp regression, or contextual to OS environment?

could be a Windows-specific bug

Yeah, at least I haven't seen that myself.

JXL is more consistent, denser, and supports higher fidelity than WebP. It resolves essentially all the pains associated with WebP, which is why the comparison is undeserved.

He said it's pretty bad "compared to AVIF", you need about -d 6 for Modular (and -d 10 for VarDCT) to reach that bpp, of course it will look bad

another odd thing. at such superlow filesizes, the loading times difference is like 1.5 milliseconds to 3 milliseconds according to jon's browsertest page

demand the receipts when you hear '2x slower' than avif (additionally firefox itself loads *all* image formats way slower than chrome)

If you're referring to https://sneyers.info/browserspeedtest/, its time measurement is inaccurate. It uses `then` to handle the promise (should use `await` instead), which means the browser can run multiple decoding processes in parallel.

that was the idea — on a normal page load of something like a product gallery, there's also multiple images being decoded in parallel

Seems Firefox is decoding them one by one though, so its decoding speed isn't comparable to Chrome

I was wondering how it performs with MT and found for 100 decodes of that image Chrome (parallel 1T) is ~40% faster than libjxl-based Firefox (sequential 4T)

makes sense

it was used before to criticise firefox's jxl integration in particular

I've got a new blogpost scheduled to go live tomorrow, titled "2026, the Year of JPEG XL"

https://cloudinary.com/blog/2026-the-year-of-jpeg-xl

2026 and we need "not written by AI" disclaimers 😭

AI starts adding "not written by AI" at the top of everything.

I thought it could be useful because I kind of imitated LLM style with all those emojis

I looked up all those emoji myself on https://emojipedia.org/ 🙂

It has happened in every domain. First the machines imitate humans, then once they achieve superiority, humans imitate the machines.

the use of em dash is something I have been doing for 15 years already though — it's just a nice punctuation mark imo

maybe starting with the robot emoji gives the wrong initial impression about the disclaimer though

maybe a human emoji instead?

meh, I too had the same initial impression, but my response is that the disclaimer is just silly and distracting

heh I dunno, the disclaimer and emojis are just for fun; maybe I could have added a human emoji at the end of that disclaimer 🧍

It would be funnier if you had a "Human disclaimer" instead, since nowadays any kind of 'AI Disclaimer' means it was used

It's a good article, preserving the historical timeline is interesting, but I think the key information introduced is the current browser support trajectory.

> 🗺️ Geospatial and Other Scientific Imaging 🛰️🔭🔬 emojiiiiiis!

Actually, the emoji style and the immediate disclaimer capture current AI interest. It's ironic and funny.

As far as the universal browser support metric, it's still possible JXL can be competitive with AVIF considering Edge's delay. But we have yet to see how Microsoft will respond to JXL on the web.

I know there's almost certainly no correlation, but I did stumble upon this yesterday https://www.msn.com/en-us/news/technology/jpeg-xl-is-the-best-image-format-that-nobodys-using/ar-AA1WaDfv

the emoji 💀

i wish there was more promotion of the polyfill based on jxl-rs. its an excellent workaround to CMSes and web services slow adoption that switches to native decoding when detected

on the article, wouldnt labelling JXL with its full name instead of its acronym/extension have been preferable ?

JXL is way more portable than JPEG XL

JXL and JPEG XL are used interchangeably in the article. fine in my opinion, if anything it helps further legitimizing the abbreviation

the only sense in which it's "officially" JXL is the media type `image/jxl` as I understand. even the file extension is just a convention and not standardized

what do we think the full name is though, because the JPEG org calls it 'The JPEG XL Image Coding System' <:KekDog:805390049033191445>

on that note, I hope the term "image coding system" catches on in the technical community a bit more because we tend to call things "file formats" even though the file structure is just one part of it

or "image format" if you don't like being fancy, though it could be argued a 'format' still doesn't encompass e.g. an encoder, which can definitely be considered part of the *system* as a whole

the bitstream, file format, encoder, decoder etc are all considered facets of the image coding system, that's how I see it

lots of terms are being used interchangeably and it often causes confusion. I try to be consistent but I probably also still make mistakes. - codestream: the actual payload representing image data in a compressed form, i.e. the payload; for jxl this is defined in 18181-1 - file format: the entire file, which can be a container, one or more payload codestreams, additional metadata; for jxl this is defined in 18181-2 - codec: short for (en)coder+decoder; also used to mean "the codestream syntax in general", not referring to what a specific encoder does - encoder: converts uncompressed image data to a codestream -> can be done in many ways, only constraint is "has to produce something that decodes" - decoder: converts codestream to uncompressed image data -> what the result of decoding should be, is the main content of the codestream specification (18181-1); how much a decoder can deviate from the ideal result is the purpose of the conformance spec (18181-3). - image coding system: all of the above, including a reference implementation (18181-4).

bitstream = codestream; image format = file format

jpeg xl is a compression format not used only in .jxl files. we use it interchangeably out of familiarity

I tend to make a distinction between what I consider colloquially correct and a consistent classification. I've been editing Wikidata and it doesn't really matter what label an entity or concept has (e.g. 'image coding system' vs 'image format') but what does matter is that it's used consistently everywhere, and the further a label gets from what it's trying to represent, the higher the chance someone will misunderstand what it's supposed to represent

The media type describes the jxl file extension. `JXL` also exists in the container signature, but maybe that doesn't count.

why not .jpxl?

In most time, bit stream = container = file extension, until someone store WebP in `.jpg` <:PepeSadCatGun:973222795150508082>

to be clear, I'm talking about the part in the file name e.g. `photo.jxl` I don't think it's defined that this is `.jxl` and I also don't think it's true that the media type is also the extension by definition, neither in general nor in this specific case, just from what I've heard from people here

Filename extensions are a common way to express what the file type is, but there is no spec that cares about the extension; whether or not it is a valid JXL file depends only on the contents of the file, and what type of file it is supposed to be when served over HTTP depends only on the media type given in the response header.

https://www.iana.org/assignments/media-types/image/jxl > 3. File extension(s): jxl

It reads to me like that's just added information for convenience, not part of a definition

because it's not wrong in practice

Not really, WebP uses a RIFF container with various payloads (VP8 codestream or lossless WebP codestream) AVIF uses a HEIF (MIAF, ISOBMFF) container with as a payload an AV1 codestream. HEIC is HEIF with as a payload an HEVC codestream. JXL files can be just a naked codestream (this is relatively unique) or they can be an ISOBMFF-style container with a JXL codestream payload. But container and bitstream is not the same thing. In most cases, the combination of container and payload determines the conventional filename extension, not just one or the other.

next blog needs this disclaimer

Now every browser know ignore MIME or file extension, and check the magic number

do you have any thoughts on when formats should be considered general purpose or not? personally I consider JPEG, JPEG XL, PNG, AVIF and WebP general purpose, despite the fact that some of these are derived from video coding systems and optimized for web delivery, they're still fit for common use, unlike for example GIF because it's not fit for common use today and DICOM because it serves a special purpose

I really hate this image lol

what in particular?

too reminiscent of .jp2 (jpeg 2000), and it’s not fully clear why the P gets to be there but not the EG

JPeg XL

(to French people, it might also sound like Jean-Pierre XL)

.mpxl for jxl in ISOBMFF

too much info trying to be conveyed at once, it's very confusing

imo .jpxl sounds better

JPEG, J2K, JXL are the only image formats I consider really general-purpose in the sense of covering the entire workflow from production to delivery. All the rest is kind of missing something, imo: - PNG does not have lossy, so it cannot really be used for photo delivery, which means it's not general-purpose (photos are probably >90% of the image bytes on the web). - AVIF doesn't have a useful lossless mode imo, so it cannot really be used for production — I mean, it _can_ be used for that but it's far from the Pareto front. Also being limited to 12-bit is a bit tight for some production workflows, 16-bit is more comfortable. - HEIC: similar situation as AVIF, plus it's a patent mess which is a (non-technical) reason it cannot be considered general-purpose. - WebP is limited to 8-bit and dimensions are limited to 16384 px, which is too limiting for production. Lossy is also limited if you want high-fidelity delivery or HDR. - TIFF can in principle do anything (it's endlessly extensible so you can also put JXL payloads in it, as was done in DNG 1.7 which is TIFF-based), but in practice you're kind of limited to baseline TIFF 6.0 if you want good interoperability. This is not suitable as a delivery format.

(JPEG is also only general-purpose if you include its lossless mode; the de facto JPEG format is not general-purpose since it's lossy-only)

> Also being limited to 12-bit is a bit tight for some production workflows, 16-bit is more comfortable. I mean technically AVIF as of recent does have a 16-bit mode but it's hacked on and boasts about being only 10% smaller then 16-bit *PNG*

hmyeah, those kind of hacked-on extensions you can of course add to any file format, e.g. Photoshop can produce files in pretty much any format which just have the entire PSD file embedded into them as a huge "metadata" blob...

is animation part of this equation? how does jpeg handle animation because last I recall jpeg doesn't support animation

good article but I feel like it fails to address the webp support situation in the other way, while production workloads and image viewers (tasks dedicated to images) have integrated jxl sooner than chrome, I don't think those are the main pain points for people who dislike WebP, the pain points are more common stuff like word documents and submitting images to non social media websites (any website which wouldn't transcode your submission) like government websites, and those situations also don't support AVIF or JXL, IMO it's an inherent limitation you can't get over even if services use tools that support these formats (like using ImageMagick).

there is motion jpeg (MJPEG) I guess, and of course J2K is being used for digital cinema, but in my view animation is not really an essential feature for an image format. There are still images and then there is video; animation is something in between but in my opinion it should be treated as video.

obviously it will take ages before anything gets adopted as widely as jpeg/png and supported in every possible application or website. But I think that webp not even being supported by Google Docs is an indication that broad support was never really the ambition of WebP — as the name suggests, it was conceived narrowly as just something between a web server and a web browser. So I do hope that JXL will do better in this respect, but of course there will always be silly applications or websites that insist that only filenames ending in .jpg or .png can be images.

I hope one day in the near future JXL becomes as ubiquitous as JPEG

well, JPEG is more or less a subset of JXL, so you want to be uncharitable you could say JPEG XL is at least as ubiquitous as JPEG :3c

I'm sure that's how that works

evil question - could you do a memcopy style transcoding between jpeg and jxl where you don't even recompress, and just build the same huffman trees?

actually JPEG XL support a subset of JPEG coding tools, so really it's a the ubiquity of JPEG XL plus the intersection of JPEG and JPEG XL, which is really just equivalent to the ubiquity of JPEG XL, and so JPEG XL as ubiquitous as JPEG XL <:Stonks:806137886726553651>

people are always upset when an image file doesn't work in their favourite program

and the problem is some of these are rarely updated

ms paint is a big one

MS Paint uses WIC, so it's already supported

Even user are willing use converter: - WebP advantage is marginal than packJPG - for high quality, WebP is worse than JPEG (no advantage at all) - WebP is the king of generation loss (JPEG → WebP → JPEG)

unfortunately, I think support is [contravariant](https://en.wikipedia.org/wiki/Type_variance) in the format (format A subset of format B -> support for format B subset of support for format A)

so like JPEG XL support implies JPEG support but not the other way round

Hmm. No, not really. Not since jpegli was removed from libjxl repo I don't think...

Really bad decision imo

Huh? Why?

And here I thought svt-av1 mainline devs made questionable decisions 🤣

I know. Makes no sense to me, especially since libjpegli could potentially help drive adoption and awareness of libjxl by being included. It was done allegedly to help Linux package maintainers, but that's not the way to do it.

To make Linux packagers happy, all you need are some instructions in the README on how to separately install libjxl and libjpegli in separate installation steps. So the packager can install them into separate package prefixes. Packagers call that "split-packages"

Specifically to me it just feels like a weird change

So jxl can do lossless jpeg transcoding but can't actually write a raw jpeg?

That's literally all that was needed. Not a huge commit removing jpegli and the constant maintenance burden of maintaining two independent copies of the same shared code in two separate git trees

Plus libjxl could have used the jpegli object code to write jpeg output instead of using system libjpeg like it currently uses

Isn't libjpeg technically worse than gli as well?

For some reason djxl never actually used that libjpegli code to write jpeg output when you ask djxl to output JPEG

In fact, djxl has code to use multiple different JPEG libraries but not any code to use its own native jpegli

Which always seemed like a huge oversight to me

When you look closely at libjxl it's really silly and confusing

jxl-rs will probably be much cleaner and easier to read. Especially for new people who want to get into jxl codec development for the first time

Not because rust is inherently superior but just because it's a clean reboot

Whereas libjxl is an old frankenstein monster

I really should yoink an artifact right B4 glis removal and do a head to head libjpeg vs gli again

It's been a real hot min

Might as well let xl converter lad know too

Yeah I hope the removal doesn't cause problems for people or hinder its adoption

It does

Cause xl converter uses gli by default

He will have to download and compile the same object files twice from two repos now

So worst case insta crash cause no fail over

The usual case gli is no longer available and error

Btw another thing that would be nice is the ability to compile multiple API versions of libjpegli rather than having to choose only one before compile

Man that also makes it super painful for custom compiles too fing a

Currently if you want to compile multiple different API versions of jpegli you have to clean build artifacts and recompile

Which is obviously inconvenient for packagers

I have experience with linux packaging and I know how package maintainers think, and this isn't going to help make anyone's life easier

Tbh idk much about compiling (am a windows pleb for now) but even still is that really enough reason to flat out delete a side lib?

I mean just look at that 🤣

What packagers want is ideally to build everything in one step and then install each component in a separate command with a separate installation prefix. With nice instructions conveniently in the README on how to install each module separately.

Like for example, this is the usual system: ```sh # build phase make all # packaging phase ## package libjxl make install-libjxl ## package libjpegli6 make install-jpegli6 ## package libjpegli7 make install-jpegli7 ## package libjpegli8 make install-jpegli8 ```

With each one going into a separate prefix folder for separate packaging

Usually there is a PREFIX= environment variable being defined before each install so they get installed in separate folders during packaging

And those folder trees become packages

Honestly I'm no good at explaining these things since I'm more of a hands on type

But hopefully it makes sense what I said

Makes a little sense, again I can't compile for crap xD

Welp did my due diligence and let xl converter lad know

Others will probably be blindsided by the change

Sadge

And technically with the change I will literally just use libjxl for lossless 😆

Use the google repo version with all he PRs merged if you can

But the point is to grab artifact that contains og libjpeg and li

To test for serious regressions

Tho kinda a moot point now since it's already gone

prebuilt dlls for jpegli couldve solved so many issues with adoption since its supposed to be a drop-in replacement for mozjpeg, especially for devs unfamiliar or unwilling to deal with the source code itself like theyre jpegli contributors

I tried to get jpegli into RawTherapee for better decode quality, but their other libraries wanted high bitdepth and arithmetic support so it wasn't actually drop-in

Yeah there are a few symbols missing like the high bitdepth stuff that's in the libjpeg-turbo

The patent is expired for arithmetic codes

https://www.cnet.com/videos/proraw-vs-jpeg-the-hidden-setting-every-iphone-photographer-needs/

https://www.youtube.com/watch?v=s8j6glUCvWY youtube version since their website didn't work for me

recommends lossy because it's a raw file type?? idk doesn't elaborate

can you really not get 12bit without raw?

<:peepothink:846277928215773194>

no,

not on these devices anyways

also on topic of that, android 17b3 just added 14bit raw

sadly most sensors in common phones (samsung) are only 10 bit

I can't speak for other brands, but probably same

they often do support 12bit via DCG but it's usually locked down in firmware

not quite 14bit, but FAR better then 10bit

custom roms can sometimes get 12bit exposed

not that anything actually useful uses it unless you have a mini 1tb nvme ssd in a USB enclosure and use motioncam...

well I think one single raw photo app can use it

I have both, but no DCG 😭

many xioami have dcg modules avaible, but pixel 10 is the first phone to support it in a stock OS

the Xiaomi 15 Ultra would be a pretty nutty phone to custom rom since it supports it with mods

It's a real shame that the custom rom scene is not as active as before

Cyanogen was great back then, lineage is just not the same in terms of broad support

but well, phones have also become boring

true, GSI helped a lot but people dont care much about it these days, android has been a bit of a pain lately [dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&name=dogelol&lossless=true)

true

I know at bliss we have had some issues for sure

I hadn't heard of bliss before, looks interesting

bliss does a lot, direct work includes, blissOS, android tv x86, waydroid, bassOS/Navotpala for corporate stuff, and work as a fiscal host for some stuff like lindroid and izzyondroid

my work with bliss is mostly around VMs like cloud and qemu and shit, though lately i've taken a back seat and mostly offer advice on shit

oh and I do documentation stuff

huh, I know all of those except for bassOS and Navotpal, strange that I've never heard of them before then

navotpala is fairly new, I think jon started it a 1-2 years ago when he left a corporate job he was pretty ticked off at since they used his foss work without proper licencing

Just found this... Something tells me they didn't turn the effort level up... https://arxiv.org/html/2603.28105v1#S4

So JXL probably would've been best if they matched encode time

Nearly 8x longer to encode and only 8% smaller

also incorrectly claims FLIF only supports 8-bit

Benchmark results that don't mention software versions and parameters are the worst, this helps spread the misconception that codec performance is fixed and unchangeable while that is never true for speed and rarely true for compression performance — only when encoding is deterministic like in QOI (and I think lossless J2K too, modulo bitstream reordering) you can talk about the compression performance of a _codec_, otherwise it is the performance of a specific _encoder_ implementation and setting.

It seems like most papers about JXL have been comparing it to ML based compression, and every time they don't list the encoder version or parameters, most times linking to the spec number instead of libjxl too so in the future you won't know what they're comparing with

This is internship work. It's fairly common for science papers to make false claims, use "non existent" software or whatever else. Even in serious and correct articles, publishing incorrect formulas and numbers without issuing a corrigendum is also common. As a result, you often have to fix these papers before you can use them. So I wouldn't be surprised that some student just put a slightly random numbers in the article.

I had 17-bit raw on a 2019 phone (poco x2)

A while ago I wondered why no camera has used floats to store the RAW data, since it's an analogue signal to start with

a floating point ADC doesn't really make sense

(or at least, not for camera applications)