JPEG XL

> The JPEG-XL-E core accepts input samples in IEEE 754 single- or half-precision floating-point format and outputs the JPEG XL compressed payload. interesting

JPEG-XL-E now even more hyphens

at least that's just a product ID, in the prose and title they write JPEG XL

Well, that was fast https://github.com/crosire/reshade/pull/399

ooh nice

I wonder how hard it would be to have the depth channel get saved to the resulting file within the scope of the simple lossless encoder and ReShade?

would be cool to get use out of the dedicated depth channel slot JXL provides

Haven't scoped into that section yet, would be nice to have that too

apparently Element Web (the Matrix client) can preview JXL images but not the images itself in browsers that support JXL, and we have no idea how

hmm maybe it's using something like imagemagick or ffmpeg to generate previews of images, including JXLs, and serving them in some other format

that's definitely it

update: I was looking at a blurhash so I gave someone a completely wrong explanation of how some JXL art was able to look like that with so few bytes. <:galaxybrain:821831336372338729>

to be fair, that could have easily been JXL art too

Might want to whitelist formats. As recent Google vs ffmpeg debacle showed, old formats are full of vulnerabilities (so many that it's hopeless trying to fix them all, there's no manpower).

"Subject: Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink Date: Fri, 21 Nov 2025 15:01:23 -0500 From: Rick Byers <rbyers@chromium.org> To: Ad <adpocalyptic@gmail.com> CC: blink-dev <blink-dev@chromium.org>, ― <hmz2798@gmail.com>, Andy Foxman <foxtrot2cz@gmail.com>, zco...@mozilla.com <zcorpan@mozilla.com>, Albert Andaluz González <albertandaluz@gmail.com>, Jarek Duda <dudajar@gmail.com>, Markus K. <markus.krainz@gmail.com>, Tomáš Poledný <saljacky@gmail.com>, Yaowu Xu <yaowu@google.com>, ash...@scirra.com <ashley@scirra.com>, jimba...@google.com <jimbankoski@google.com>, jz...@google.com <jzern@google.com>, vign...@google.com <vigneshv@google.com>, s...@chromium.org <sky@chromium.org>, w...@google.com <wtc@google.com>, yoav...@chromium.org <yoavweiss@chromium.org>, dah...@chromium.org <dahlke@chromium.org> Hi everyone, Since JPEG XL was last evaluated, Safari has shipped support and Firefox has updated their position. We also continue to see developer signals for this in bug upvotes, Interop proposals, and survey data. There was also a recent announcement that JPEG XL will be added to PDF. Given these positive signals, we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder in Chromium. In order to enable it by default in Chromium we would need a commitment to long-term maintenance. With those and our usual launch criteria met, we would ship it in Chrome. Rick (on behalf of Chrome ATLs)"

HUGE

2025 sure is going out with a bang

Thanks for forwarding it here

Congratulations! here is the link: https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/NmOyvMCCBAAJ

oh man this just made my weekend

This year sure is fucking insane lol.

The year where everything happens.

The best possible JXL news just dropped my god 🥳

Pour one out for the poor devs, as if they weren't busy enough 😅

And now I have more incentive to hury up my encoder improvements

they even spelled it right, that's how you know they're serious

nope

still no love for the non-breaking space...

One thing to note here, is that unlike Firefox, Chrome doesn't use a JS-based PDF reader. PDFium is a native library that depends on native image libraries. So they would've had to add a JXL decoder to PDFium, and thus Chrome, sooner or later. Mayne not until like 2027 or so, but definitely eventually. The whole argument against jxl was increased attack area, increased maintenance burden, and increased code size on constrained platforms like phones. But all of that is irrelevant if they need to ship it anyway.

I wonder how Interop is going to go now

jxl sweep

The other day Firefox assigned someone to the JXL bug so looks like they are moving forward as well.

They've been working on it for weeks, just a lot of dependencies to sort out first

how ready are jxl-oxide and jxl-rs for integration?

I think JXL-rs once finished is designed to be the integration

YES!!!

not yet but soon™️

honestly all they really need is a somewhat stable api anyways

It already is integrated https://discord.com/channels/794206087879852103/803574970180829194/1412813772988612718

Yay, well done everyone <:heyjam2Jamcheer:1436610418033557534>

HUGE news! GREAT NEWS!

Wow, you know it's big when <#803379415106584626> finally gets updated xD

Still no sight of libjxl's 1.0 release.

All eyes are now on jxl-rs to be production ready for Chrome and Mozilla

new post just now with a wip implementation (still using the c++ libjxl)

Damn, that was fast >>> Great to hear this! Recently started working on this -> https://chromium-review.googlesource.com/c/chromium/src/+/7170439 Current status: - Feature complete - used the previous JXL implementation as a blueprint and updated to the most recent reference implementation - Added animation support (Chromium would be the first browser to support JXL animations) - bots are green (Except size increase jobs; i have no clou why it ignores my commit hint) - guess still needs several rounds of feedback and optimization work. I'm happy to collaborate with anyone interested in reviewing and optimizing this further. Here's a demo video showing it: https://youtu.be/zVkX4bP6qSo cheers,

we'll need to update this now

In my opinion the C++ libjxl library should be finished as well; no one's gonna want to use the Rust library for their C/C++ projects.

it is finished

well finished is a big word

Many projects don't consider libjxl finished until the 1.0 release.

that's not necessarily an indicator of whether a project is finished

libjxl isnt getting abandoned. decoding was pretty much 1.0 since long with 100% conformance. encoder will keep getting improvements, tuning, profiling, etc - do note it was supposed to only be a reference implementation, it just raised the bar really high

I mean the 1.0 release would be considered formally finished by many FOSS projects.

I think you might be overestimating their reliance of the version number, to be fair

the versioning is only misleading for folks unfamiliar with why 0.10 comes after 0.9 - decoder's version only matches encoder's since improvements to both are rolled at the same time, not because decoder was alpha-state

if projects don't want to integrate libjxl until it's "done" because they see it's still on 0.X, it's probably good to tell them that the decoder is fully feature complete and already used in many mainstream software

Many projects also want the encoder to be finished and tested to work correctly with the decoder hence the reason they're asking for 1.0.

what does it mean for the encoder to be finished

I thought v1.0 was just API stabilizing not necessarily the encoder being "done"

with how many features JXL has it might be [wild guess] decades before the encoder tries to utilize *all* coding tools

its 2025 and jpeg1 still doesnt have its full features implemented by anyone. even jpegli caps itself at level 6.2 just because its what became the defacto standard since 2000

some ecosystem advances are only possible when both encoders and decoders update in tandem, like through auto or platform updates

Even that'd be desirable.

If conformance means 1.0, jxl-rs was finished weeks ago

https://github.com/libjxl/libjxl/issues?q=state%3Aopen%20label%3Av1.0

Yeah some issues are tagged with "decoder". Not exactly ready.

Only two, one is something about XYB and ICC, the other is adding a new feature for cropped decoding

the conformance table needs an update properly reporting the latest progress (timestamped, or automatically checked/updated?). verbal assurances do nothing when anyone sees this suggesting pre-alpha conformance https://libjxl.github.io/bench/

It'd be nice if it could run as a github action once a week or something

which ones

Isn't this kinda pointless as their announcement specifically said "memory-safe"? I read this as clear notch towards the rust decoder

Probably. But I am assuming Safari has been using libjxl for a while now, so there has been quite some exposure already. If there's a libjxl security bug, it would impact all iphones.

yes, but Chromium presumably will not integrate anything but jxl-rs

though, it's not bad for comparing capabilities, performance, and decoding accuracy, and also, if there is already a base, it will be easier to replace it with a different decoder, especially if some APIs are similar also it's not like starting from scratch, since libjxl has been added before (just need to update for new versions and api changes)

At least GZDoom was not considering it until 1.0 releases. The API isn't finalized yet if the 1.0 tagged issues in the repo is anything to look at.

I don't think that there any any breaking changes planned for the decoder side of things (just feature additions)

but for the encoder, fair enough

At least ability to simply detect JXL files in a fast manner would be appreciated.

i see, I thought there were many projects

Can't that be done with the signature at the start of the file?

FF0A

or if the ISOBMF container is used, 00 00 00 0C 4A 58 4C 20 0D 0A 87 0A

I'm presuming this is in little endian.

And that both signatures are guaranteed to start at the beginning of the file.

Yes, these are initial bytes

it's `ff 0a`, `0x0aff` in little endian

Thanks for clarification.

libjxl already has a method to do that: `JxlSignatureCheck`.

yea you can just `memcmp(file, "\xff\x0a", 2)` pmuch

but JxlSignatureCheck also works

This is BIG. Native default Android support next?.. What's the status of the rustlang? Does it support stuff required to make jxl-rs fast yet?

Rust does yeah. I'm not actively following development but jxl-rs is feature complete and most effort is spent optimizing it at this point I believe

It's only around 2x slower now for most decoding, and multithreading isn't implemented yet https://discord.com/channels/794206087879852103/803645746661425173/1439179374044909599

(Effort 1 has since been sped up 2x)

Add JPEG XL decoding support to Chromium using jxl-rs https://issues.chromium.org/issues/462919304

Oh nice, I was just looking at the PR they made on rs for HDR ICC tonemapping

slightly confused by that hdr stuff, because it seems like libjxl-rs already writes a cicp tag? so why wouldn't that get passed through to chromium like with pngs

also, what software is that tonemapping clut in the icc profile even useful for? firefox used to support them but last time i checked they don't anymore, and chromium never used them afaik

nvm i can't read, icc profiles for hdr just didn't work in libjxl-rs

still not sure what software actually uses those luts though

who made this issue though? anyone can open chromium issues

oh _Helmut Januschka_ im assuming

are they part of chromium or not? its kind of hard to tell

> I work as Head of Engineering at krone.at, focusing on engineering management, technical strategy, and system reliability. My background spans 25+ years across various technology domains. > > I contribute to open source projects including Chromium, LLVM, PDFium, and Fastlane. Areas of interest include system performance, developer tooling, and infrastructure automation.

> Major contributor to Google's open-source web browser project. Led modernization efforts including StringPiece to std::string_view migration and GoogleTest naming convention improvements across multiple modules.

so good chance of that getting merged i guess

They're the one who did the libjxl integration yesterday, made the youtube video, and then did jxl-rs integration today <https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/NeiCV32tBAAJ> <https://chromium-review.googlesource.com/c/chromium/src/+/7170439> <https://chromium-review.googlesource.com/c/chromium/src/+/7184969>

also https://github.com/libjxl/jxl-rs/pull/491

unfortunately its not so simple for image formats

Even WebP support on Android has been inconsistent as fuck.

unlike WebP, JPEG XL is intended for things other than web delivery so it's more likely to be useful and wanted in apps than WebP is

that's not the issue

the issue is "adding support for android" isn't a thing

many apps use many different frameworks

If Samsung adds support to their preinstalled gallery we will have finished a good amount of the way

I was moreso talking about that the main reason there is demand for WebP support, is that people inevitably end up with them because they're used for delivery. it's not an appealing format per se (except the really good 8-bit lossless mode)

the best you can do is make sure the mime is recognized, which iirc it already is, and add support to https://developer.android.com/ndk/guides/image-decoder

which is in the android NDK and AFAIK I dont actually think the ndk is open source is it?

dunno it's been literal years since I touched this part of android

basically, get skia working with jxl nice and well, and go from there, I don't have the time to work on this, but now would be the time for an android dev to do so https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/native/graphics/jni/imagedecoder.cpp https://cs.android.com/android/platform/superproject/main/+/main:external/skia/include/codec/

> Rust does yeah. I looked it up, looks like not yet.

stuff required to make jxl fast like simd and multithreading?

you weren't very specific

I don't believe we're blocked on anything on the Rust side

there's plenty of stuff that would be *nice*

but nothing *necessary*

Well that escalated quickly. Wondering how the second attempt at chromium integration goes. Chromium seem to be building with recent rust versions <https://github.com/chromium/chromium/blob/6e1ca2e0c395e4bf4ba4ab55170346ff108c1a4e/tools/rust/update_rust.py#L39C18-L39C58> -> this goes to fairly recent rustc commit <https://github.com/rust-lang/rust/commit/11339a0ef5ed586bb7ea4f85a9b7287880caac3a>. At least on the toolchain side there are no blockers for integration like in the case of Firefox. Still think it'd be worth freezing jxl-rs MSRV to at most 1.90 to give Firefox a chance.

Interesting: <https://issues.chromium.org/issues/462919304#comment2> > While Microsoft goes through our internal evaluation process for adding support to our browser [...]

So there's a confirmation that JXL support may land in MS Edge regardless if it lands in chromium

I think it's the opposite. MS wants it so that you need to install JPEG XL extension from MS Store before you can view JXLs in Edge. AVIF went through similar process on Edge, it was literal years before MS's bureaucracy machine allowed it to be on by default.

Plus the MS AVIF and WebP codecs were broken beta software the last I checked, but maybe they fixed them at some point in the last few years. The MS AVIF codec couldn't even correctly load the test images with transparency that Microsoft contributed to the AVIF conformance suite. 🤣

Though JPEG XL is not as encumbered with patents as AVIF, so hopefully "evaluation" will be quicker

MS AVIF can't decode YUV444, and other bugs

They fixed that in an update a few weeks ago

Ah, so not good then :(. Indeed AVIF in MSEdge landed more than 3 years after chromium inclusion.

Wasn't one of the main points of AVIF that it's royalty free?

AV1's status is questionable at best.

A better bet would be to wait for HEVC patents to expire in 2035 or something.

At least that should replace the ancient VPx codecs.

even if AV1 is free from patents, AVIF uses a container that isn't

not sure why they made that choice

not quite free from patents, but you get a free license with a defensive termination clause

Doesn't jxl also use isobmff?

optionally

Also known as .mov/.mp4/.3gp/.heif

If it was a patent issue then jxl wouldn't have chosen it...

there's the simple container format that is used in the jxl file format: this one is pretty safe patent-wise since the only "technology" is basically from the 1980s/1990s and is pretty straightforward (4-byte box names with a 4-byte size field, even PNG uses that concept) and then there's the more complicated HEIF that is using that syntax but defines lots of additional stuff like layering, tiling, rotation, cropping, etc. That's a newer thing and Nokia does claim to hold essential patents

Oh, I see. I didn't realize heif has patented parts

The ISO documents referenced in the AVIF container format specification are also expensive. Although the ISO makes some versions available for free, IIRC that included an older version of the ISOBMFF spec.

probably in a next edition of 18181-2 we'll also define HEIF with JXL payload, but just as an optional thing. So then there will be three types of jxl files: - raw codestreams (just a naked 18181-1 bitstream) are valid files and can do anything you need to fully represent an image (sample data, colorspace, orientation, etc) - jxl container: simple and lightweight container, useful to embed metadata (XMP/Exif), jpeg bitstream reconstruction data, gainmaps, and whatever other "additional stuff" you may want to include besides the image itself - heif: more complicated container with more container-level functionality, also can store image collections etc

speaking of the spec, I remember a few months ago hearing that something was being added or changed related to JPEG recompression to allow for handling/decoding of some types of side data (like gainmaps? \🤢) that would normally only get used during JPEG reconstruction. but I have to ask since I'm unfamiliar with the changes/additions exactly but is it structured in a generic enough way to theoretically allow/support things such as [JPEG XT](https://jpeg.org/jpegxt/)? <@794205442175402004>

~~off-topic but it seems like Discord's markdown support doesn't like rendering non-breaking spaces~~

we have been discussing that but there's no concrete proposal yet, probably we'd first implement that in an experimental branch of libjxl before adding it to the spec

Why use ISOBMFF when not need multi stream and random seek?

(AVIF use 2nd stream as alpha channel, support inter prediction same as video)

Since Heif with av1 is Avif, then Heif with JPEG-XL will be JEIF? 😄

JEIF sounds like an ultra cursed pronunciation of GIF

Reminds me of JNG.

Well, there's HEIC. JPEG1-in-HEIF doesn't have any special file extension.

Nokia's lawsuit will get laughed out of the courts tbh; patenting container formats is just dumb.

IIRC ISOBMFF was used in MP3?

MP4

Makes sense.

But yeah, ISOBMFF was created in 2004, so Nokia is grasping for straws.

There wouldn't be much reason to use the heif container with jxl payload, actually I resisted defining it exactly because it's not really needed — at least not like it is needed for heic and avif where without heif you wouldn't have a way to do alpha or arbitrary ICC profiles. But there's an interest from the heif folks to do this, so if they want to add that option, I'm not going to stop them.

HEIF (23008-12) is more recent than ISOBMFF (14496-12). ISOBMFF is from 2004 as an ISO standard but it was already used earlier in MP4 and also in JPEG 2000, and it's basically just QuickTime. HEIF is from 2015 and it's currently 145 pages of spec that has ISOBMFF as a dependency.

Yeah I remember that https://discord.com/channels/794206087879852103/805176455658733570/1056109820979183676

https://tenor.com/view/jod-gif-22535623

the cloud cover splits. an opening appears. rays of light illuminate the lands below. down from the heavens they descend. not in physical form, but certainly there. not observed by any senses yet palpably, definitively, manifestly, present. not a person, not an animal, not a being, not alive, nor dead, but a concept. God. they've been here for 15 seconds, but it feels like you and everyone around you have been stuck here for days, nay, weeks. then, they communicate but once "it's pronounced Jod" they leave

jxrlib doesn't support JXR-in-HEIF though?

I like how in Captain Disillusion's video about alpha transparency, in an effort to intentionally produce PNG wrong, they incidentally pronounce it right as something very close to "ping"

Used 2 B NOKIA. NOKAI nowadays. HAIP3D.

Nevermore https://bugzilla.redhat.com/show_bug.cgi?id=1979565

I wonder if Adobe and Affinity will start using JXL lossless in PSD and Affinity files… Would make sense.

My drive could certainly use it.

If they did they would probably misuse the JXL format in some annoying way. like for example treating JXL like it doesn't support layers and rolling their own layering system with unneeded overhead

I mentioned a similar idea to the Krita devs a while back https://bugs.kde.org/show_bug.cgi?id=500877

imo some use of jxl for psd at least will happen eventually. imaging-focused proprietary formats could rebase on clean jxl-based specification to simplify futureproofing them

simple steps first. some apps like gimp silently flatten multilayer images to jxl without even a warning. big issue

That's why it is called Export and not Save as...

Photoshop layers are quite convoluted, though. No format is designed to take those layers except psd.

I was hoping that Photoshop/Affinity/Krita/Gimp could use JXL as a "Save" format, where the (layered) image data is stored as jxl layers, if needed as invisible layers and with an explicit merged image (because funky blend modes or other fancy stuff is used that cannot be represented in jxl), and all the proprietary/additional stuff that is editor-specific is stuffed in some application-specific box that is only used when loading the image in the editor.

Photoshop kind of does something like that when you save as TIFF or PDF, it just stuffs all the photoshop stuff in metadata blobs in those formats.

I'm still a bit disappointed that DNG doesn't use CFA layers

not that it matters for any practical reasons, but it would have been nice

I guess for now the main one using JXL DNG is the iPhone Pro, which doesn't use CFA anyway but "linear RGB", so for that it doesn't really make a difference

but yes, it would have been nice to use CFA channels instead of just using single-component codestreams; it would potentially allow better compression since you could use RCTs and prevchannel MA properties...

also would have been nice to use the jxl internal tiling instead of using dng tiling with lots of small codestreams

would have been even nicer to use the JXL file format and put the DNG stuff in a box in there 🙂

but there's still a strong tendency to see payload codecs as a black box that encodes a 2D array of numbers and anything else is application-specific and reinvented again in every container whether it's DNG or DICOM or HEIF or PSD

especially the two green filter channels that are in basically the same channel twice

DNG being a JXL with special metadata would have been really nice yeah

one thing I can see JXL adopted in is game dev, where assets can have color channels, normal maps, reflectivity and all sorts of other properties efficiently stored in a single file per texture asset

at least during development and distribution, you'd have to decode them to something else to get it onto the gpu

The 1 billion jxl per day number was a bit of a peak (stable number is more like 700-800 million), but this week we're hitting new peaks — as always this time of the year, the Black Friday / holiday season effect is kicking in — and we're now around 1.5 billion jxl images delivered per day.

possible to give an idea about some point? what percentage of the total jxls *generated* is generated from a jpg original and from a png original (assuming originals only get one jxl output generated instead of several in multiple resolutions)

https://github.com/elias1518693/jpeg_textures I've been working on something so that you could even use JPEGs without decoding them to something else. But currently it only works for JPEG because writing a JPEG XL decoder on the GPU is a bit complex and you have issues with all prediction it does since it further complicates random access 😅

I cannot answer that in general, but for Cloudinary: most original images are jpegs, though we have all kinds of other formats being used for originals (png, psd, tiff, heic, camera raws,...). But it's very rare to just transcode originals without doing at least a downscale, and usually other transformations (crop to change aspect ratio, add overlays, sharpen, etc etc). So we always encode from pixels and it's hard to say what the original format even was, e.g. say you start from a camera jpeg, downscale and crop it, sharpen it, and add some text overlay and a logo from an svg file, would you still consider that "a jpeg original"?

Interesting. I'm not sure what settings you encoded the JPEGs as, but doing XYB JPEG on the GPU could give a few more percent. For JXL, you might wanna look at the features the recent hardware encoder is using. You probably don't need all the features of the format for a game texture

yeah I tried that but did not get the correct color conversion to work. Currently I support 4:2:0 subsampling to get 16x16 MCUs which lets me also store less offsets (which are needed for random access)

after all this time, i'm still surprised that it was apple of all companies that pioneered having jxl support

right?

having Safari be the main major browser to support JXL was wild

I guess they saw the importance of adopting it into their ecosystem because unlike Google and Mozilla they're also big in media production with their video formats and editing software

Apple really likes premium things, and JXL is a premium thing

Just wish they'd let us convert our JPEGs in Photos already.

Once patches are ready, I wonder which browser will be the first to integrate it in non-nightly non-beta build: Chrome or Firefox.

probably chrome, ff takes forever to move features

origin trials will make the difference. those for chrome, firefox and edge are separate

i hope this time the mistake of not doing them is not repeated - origin trials are how browsers forcefully enable a certain flag for predetermined list of websites