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

Will it go through origin trials? AVIF didn't get one https://chromium-review.googlesource.com/c/chromium/src/+/2261172 And I think some of the reasons listed there also apply to JPEG XL

the difference is that there was next to no risk in enabling it

enabled by default would be fine if it goes through the normal continuity (canary->dev->beta->stable). thats at least a month's worth of feedback and tuning. will still need cooperating partners (cdns are ideal but shouldnt be the only source of feedback)

Why Google's git so hard to use

gerrit?

https://github.com/bearcove/dodeca/commit/edd0f8601872d8f35e8b382a213127b7397950a3

not sure how handy this static site generator is but hes got hundreds of paying backers and corporate sponsorships from aws and zed editor

I've always thought of the software an excuse for them to write articles about building it 😛

nobody gets views praising webp

to be clear I didn't mean in a clickbait sense: they write educational articles about Rust, and you can get a lot of educational content out of writing about writing the static site generator you conveniently happen to need in order to hold the site that contains said content

I like [their videos](https://www.youtube.com/@fasterthanlime/videos) too

Guys guys guys guys

bragging about JXL to a friend. send a JXL file to facebook messenger

did you know this?

yeah, since 2022 IIRC?

https://www.reddit.com/r/jpegxl/comments/pr2sk6/facebook_now_seems_to_accept_jpeg_xl_image_uploads/

2021 apparently

ah, so it's apparently very much not new

I wonder if it *serves* JXLs based on the user-agent or accept header?

they did an experiment for serving jxl (on mobile, most likely) in 2021/2

im more surprised it could even parse jxl art and show a preview of that too

Seems like support has improved, in that thread people mention that bare JXL doesn't work, but JXL art obviously never uses the ISOBMFF container.

anyone here from fb can talk this up?

telegram also supports JXL, but it "compresses" JXL to a low-quality much bigger JPEG lol

Sending as a file allows the in-app viewer to load JXLs on desktop

oh! so it does! very cool 😄

It even recognises animated JXL... But doesn't display it properly, just gives it the `GIF` tag like muted videos

at least EOG displays animated JXL, that way I don't have to go and hunt down a viewer just for that

The only official source we have is this <https://issues.chromium.org/issues/40168998#comment17>

who's that guy from meta? maybe a rep of the jpeg group or the jxl authors could contact them to at least bring up awareness blink itself (not just chrome or chromium) is restoring jxl and want it enabled by default

smugmug/flickr could probably use a highprofile nudge so they could be part of upcoming early adoption testing

I think they'll notice

More info on a hardware encoder > Thanks to its efficient architecture, the compact encoder core achieves a latency of just one frame and a processing throughput of one sample per clock cycle. A single instance can encode 4K-resolution images in real time, while multiple cores can be instantiated in parallel to support higher resolutions. 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. https://www.cast-inc.com/compression/jpeg-image-compression/jpeg-xl-e

ooo there's even some details on the right side of the website about encoding features and supported input(s): > ## JPEG XL Encoder > > * Compliant to JPEG XL ISO/IEC 18181 > * Lossy (Var-DCT) compression > * Supported Features > * Gaborish filter > * Quantization/Field value: 1-255 > * Quantization/Scale value: Arbitrary > * Quantization/Matrix value: Fixed > * DCT block size: 8x8, 16x8, 8x16 > * TOC order: Fixed > * Entropy coding: Prefix code (fixed table value) > > ## Input Format > > * Horizontal Resolution: 320-4096 > * Vertical Resolution: 16-4096 > * Color format: LinearRGB, > * RGB (perceptual quantization) > * Bit depth: IEEE 754 > * Single- or half-precision floating point > > ## Throughput & Latency > > * 1 sample/clock throughput > * 1 frame latency

nice to see it uses more then one block size IMO

This is probably a pretty direct translation of jxl-tiny

Which uses those block sizes

oh huh yeah: https://github.com/libjxl/libjxl-tiny/blob/main/doc/coding_tools.md

Yeah, Shikino did use libjxl-tiny as a starting point; but of course lots of stuff needed to be adjusted to make it hw-friendly, in particular everything is done in fixedpoint, and the hw version traverses the data in a more parallel way also within a group. But in terms of compression performance it should be more or less similar to libjxl-tiny.

I'm surprised it uses different block sizes at all, pretty nice

prefix coding is unfortunate

I imagine it's possible to construct an ANS JXL from one that uses Huffman coding though

I'll note that down for CSALT in case people do JXL -> JXL

https://github.com/webmproject/CrabbyAvif/pull/703 I didn't expect that

CSALT lossless mode? 😉 looking at libjxl-tiny, you can also do the coefficient reordering you've mentioned before as well as redo the LF image at a higher Modular effort (it uses a fixed tree)

> CSALT lossless mode? I guess so! it doesn't really fit does it

optimizing JXLs losslessly sounds like it could be a different tool entirely

yeah I agree, but potentially fairly valuable in a world with hardware coders and/or as an archival tool (jumping to https://canary.discord.com/channels/794206087879852103/794206087879852106/1446849837155877006)

prefix coding is in the spec specifically because it is convenient for hardware encoding. The encode side of ANS is hard for a hw implementation.

so yes there should be room for lossless jxl->jxl recompression by applying better entropy coding, the hw encoder is limited to predefined huffman codes because anything better would require more buffers and a two-pass approach

we were talking about it in <#794206087879852106>. I think if hardware-encoded JXLs become common, it'd be nice if cjxl had a mode specifically to losslessly optimize lossy JXLs, as a default mode when the input is VarDCT and the distance is 0. just like how it already has an implicit mode for JPEG recompression

https://tenor.com/view/why-huh-but-why-gif-13199396

"JPEG-XL" from an iPhone 17 Pro Max at Apple Store Taipei 101

iphones had jxl for proraw for over a year hasn't it?

Just wanted to confirm if the hyphen still exists

<@&807636211489177661>

i wonder when will the first android phone incorporate this

surely we will get general software support for android in 2026 [copium](https://cdn.discordapp.com/emojis/1309186253652234281.gif?size=64&animated=true&name=copium)

And how is the subjective quality of libjxl-tiny?

Better than mozjpeg?

You mean at the same filesize I assume?

Of course

I never saw anyone do any detailed subjective quality analysis of the -tiny encoder.

Does it beat libwebp?

What sort of artifacts are expected?

Considering the target quality is 90-95, yes

We haven't done subjective tests but in this very high fidelity range, the metrics are probably reliable enough.

Actually, apple removed lossy bayer JXL DNG support starting from iOS 26.1 (I don’t know if it’s a bug or on purpose)

Apple never had Bayer DNG

Yes, they don’t output bayer DNG. I mean in previous iOS versions(17.0 - 26.0.1), they can render bayer dngs correctly but not after iOS 26.1

They failed to render interleave stored bayer data(needed for lossy JXL). My guess is they use a new DNG decoding process on iOS 26.1 but forgot to add the interleave data pattern support.😅

I’ve already sent feedback to apple but no replies and iOS 26.2 still has the issue. Does JXL developers have connections with apple developers?

One can reproduce the issue by using Adobe DNG convertor with parameter -lossyMosaicJXL on a normal bayer DNG. The converted DNG will render complete black on devices after 26.1

I was going to ask, do you know if the HW encoder's block merging and quality decisions are based on libjxl, or was it tuned standalone since it only goes up to 16x16 blocks and is focused on high quality?

I'm wondering if the overzealous merging and B desaturation of main got into it...

It should be similar to whatever libjxl-tiny does

libjxl-tiny has the same desaturation issues as libjxl from what I've seen

https://github.com/web-platform-dx/developer-signals/issues/215

I'm glad I raised attention about that. The interop has been running for years with hundreds of votes, but the dev signal only had 40

The desaturation issue is an achilles heel and I really hope jxl doesn't become known for and associated with desaturated colors. I'm pretty sure the cause is due to the quant rounding error always undershooting the target on average because it doesn't take gamma into account when computing the error

It's a theoretically easy fix, the issue is parameterized quant tables is the one kind that isn't implemented yet, so we'd have to do it from scratch

So the encoder doesn't actually calculate the true severity of the rounding error and does not attempt to compensate at all for consistently undershooting the target

You don't actually need to change the quant tables to fix. You just need better error prediction and compensation technically.

Preferably using some fast, good-enough heuristic that can even out the bias

Some black magic multiplier that causes the rounding error to average out closer to the center of the target rather than consistently beneath the target

Yeah, it rounds towards 0 rather than the closest number

Hopefully it gets fixed in libjxl-tiny as well, before hardware encoders cement desaturation into libjxl reputation...

Luckily since it's a problem with rounding error, it's not a big deal on high quality settings

I did my testing of libjxl-tiny at `-d 0.45` and it was still noticable in some areas

Hopefully it's less prominent in photos where there's a lot more going on in general

Hopefully someone comes up with a fast little hack that's good enough to offset the bias

do we know if these hardware encoders necessarily have the relevant parameters hard-coded? maybe they can be configured properly to get around it?

maybe it has support for parameterized quant tables, despite software encoders not having those. it'd make sense to go through that effort for a hardware encoder since there's a high risk of...well, stuff like this, and not being able to fix it down the line

Hopefully the desaturation issue can be patched before it becomes something people notice enough to become a part of JXL's reputation

"That format that washes out all your colors"

It's not a problem that's inherent to XYB or JXL, but just with how it's implemented.

It's theoretically possible to compensate for.

In the encoder.

https://github.com/kaitakeradiology/orthanc-jxl

> Center-first group ordering for streaming applications Yes but actually no, chunked broke it > The plugin currently defaults to ProgressiveLossless mode with center-first group ordering. Ah, well that disables chunked... And is 40% larger than it should be because v0.12 still isn't out, along with being singlethreaded

Thanks AI... I did install a nightly locally. Will make a few updates.

https://github.com/hjanuschka/jxl-ui

hjanuscha is on a roll. mentioning because this (mac) image viewer specifically implements jxl-rs as a decoder

Interesting logo

https://raw.githubusercontent.com/hjanuschka/jxl-ui/refs/heads/main/assets/icon.png

there's a bit too much empty space and it causes it to look out of place next to other apps: https://cdn.discordapp.com/attachments/978083166239744081/1448113376399069297/Screenshot_2025-12-09_at_6.45.28_PM.png

Unnecessary name on an icon

Keka's icon has been updated for macOS 26 Tahoe however

seems jxl-rs got some initial merge into chromium yesterday? code appears to be part of 145.0.07572.1

the rust lib got a ton of improvements, ressource consumption reduction and faster so does that mean theyre confident further implementation adjusting can be continued as part of the browser or blink ?

https://chromium.googlesource.com/chromium/src/+/740e9bb6eda1faec82bb17e11f87b7313b46a137 https://chromium.googlesource.com/chromium/src/+/refs/heads/main/third_party/rust/

for now it's just initial integration, connecting this to Chrome can be done mostly in parallel to improving jxl-rs 🙂

in particular, a lot easier to have 0.1.4 and use that to build the Chrome scaffholding and then update everything later

speaking of, how much communication is there between you and the Chrome dev who has been submitting a bunch of PRs? I'm asking because it seems like they are generally unaware of what your plans/roadmap are in relation to jxl-rs.

I mean he opened a million PRs, we're talking 😛

I just have been too busy trying to write a bunch of code before reviewing them

You mean Helmut?

yep

I wonder if an eventual encoder implementation could make it into browsers for cache compression? for losslessly transcoding cached JPEGs into JXL to reduce the amount of data stored, or rather increasing the amount of images that fit in the cache, typically limited to 1 GB total

There was a Chromium issue open about JPEG XL content encoding, but the issue errors when I try to open it now

The group works though https://groups.google.com/a/chromium.org/g/blink-dev/c/4hFGYxBRIBU/m/dUgy9SUVAgAJ

that'd be nice

I assume responses are cached in their original encoding so it'd benefit cache capacity too

Maybe this one? https://issues.chromium.org/issues/40141863

Nearly >>> See: https://bugs.chromium.org/p/chromium/issues/detail?id=1088429

Leads to intranet.

I've been thinking, should someone reach out to that company making the hardware encoder to tell them about the desaturation issues their encoder likely inherits from the software encoder they used?

I can reach out to them but it would be better to have a libjxl-tiny patch ready first to show how to fix it

Is the saturation bug only present in libjxl-tiny or also present in libjxl? It's seems like a pretty serious bug

Reaching out would be a pretty good idea. As many implementations of libjxl shows the end-user devs of the library often don't research in depth (misusing stuff etc.)

it's also in libjxl. the issue is with the default spec-defined quantization tables

the format allows signaling different quantization tables, but that's currently not supported in many (any?) encoders

if the hardware encoder allows signalling different quantization tables via parameters, the issue will be easy to fix by any device using it. but I don't know whether that's the case

Probably no device is using it yet

libjxl has an API for full quant tables, but not the parameter version

Will this be fixed in libjxl before next release? And what can I currently do without being impacted when converting to JXL?

That depends when the next release is

Is there any way to prevent the bug currently?

And in what situations does it show up? If it's always been a part of JPEG XL it has been unknown for quite a few years I guess

Quite fascinating in a way. Hopefully it won't have any long-term impact

It only affects highly saturated yellows and sometimes reds from what I've seen, so you won't notice it unless you're comparing to the original or know what to look for

I would say it's not as bad as the desaturation of reds and blues you can get with JPEG, but it is something that would be good to improve.

Could I impose on you to expand on this a bit? I'm really struggling to understand best practice for lossless progressive compression, the docs are fairly sparse and the encoder seems to have moved on quite a bit without a formal release.

So it's actually not really a unique mistake to have? To be fair doesn't all codecs have their own "look" in a way? In a way we're for example used to look at how JPEG artifacts can look at decent quality settings

It's almost expected when looking at images. If I remember correctly I've seen criticisms of JPEG XL probably relating to this exact thing. We're so used to how JPEG compression artifacts look we expect them as part of the picture

I mean in jxl we can in principle avoid this specific problem. Unlike JPEG's problem with red and blues which is hard to avoid since it's mostly caused by YCbCr and chroma subsampling.

Yellows, orange, reds, and even greens too.

I haven't noticed it with blues but that makes sense since the human eye is much less sensitive to blue

And yeah most encoders have a lot worse artifacts but libaom has made huge leaps and strides recently

libaom does a really good job these days

Yee, can't do 0,255,0 for instance

The color desaturation problem is somewhat unique to the XYB conversion process. Other codecs do not have a similar desaturation effect, but they have different problems such as chroma blurring and resampling artifacts when chroma subsampling is used, or heavy artifacts in dark, low-contrast regions is another common issue with a lot of codecs.

The B channel rounding/quantizing towards 0 makes it stronger, so it makes sense you wouldn't notice desaturation, since it would only make it stronger (As far as my testing showed)

A TLDR is: Use main instead of 0.11, `-d 0 -p -e 9 --group_order 1` There are some more tweaks you can do, but they have varied results for only slight improvements

That's awesome, thanks for clarifying. I'm running a nightly in my testing.

I might stick with e=7 though: ``` Benchmark Results (512x512 16-bit CT) | Mode | Effort | Encode | Decode | Size | Ratio | |---------------------|--------|--------|--------|-------|-------| | ProgressiveLossless | 7 | 63ms | 6.5ms | 114KB | 4.5x | | ProgressiveLossless | 9 | 191ms | 11ms | 113KB | 4.5x | | Lossless | 7 | 25ms | 6ms | 92KB | 5.5x | | Lossless | 9 | 87ms | 4ms | 90KB | 5.7x | | Lossy (d=1.0) | 7 | 35ms | 2ms | 20KB | 25.6x |```

I thought 0 means "not blue nor yellow"

Like how if everything is zero in the chroma channels, it's grey.

Huh, I hadn't seen that decode speed penalty from e9 on progressive before. I might look into that later

https://github.com/weserv/images/commit/a8abac275128ecc8fa43d203f5551c99fc98a0a9 - coming soon to https://wsrv.nl/

hooray

Yay!

Was checking on the Chromium integration and I'm a little unsure about this. Before it was only a filesize check, which for things like JXL art, wouldn't stop anything. But now it's limited to 67 MP, so anything above 8192 * 8192 will fail to decode. Definitely not a common scenario, but seems quite low even compared to WebP's 16383 * 16383. The original libjxl implementation never had a limit at all

It was only done for AVIF to detect invalid files > // The maximum AVIF file size we are willing to decode. This helps libavif > // detect invalid sizes and offsets in an AVIF file before the file size is > // known. > constexpr uint64_t kMaxAvifFileSize = 0x10000000; // 256 MB

<@179701849576833024> thoughts on this? I'm unfamiliar with the code but if it really is limiting to files with a max res of 8K with the changes hjanuschka made here then that's wayyyy too low

ah no, the size is too low for sure

what would be a good res limit? 32K? 64K? something else?

I'm in favor of 64K although I haven't really thought much about it and maybe there's stuff I'm not considering 🤷

`1024 * 1024 * 1024` would be 16K, 1GB of memory as an 8bit image

what are the limits for PNG and JPEG? or are those just file size based?

level 5

so `1024*1024*1024`

what would make sense is to just use the Level 5 limits, which is 262144px max for each dimension and 268 Mpx max in area.

JPEG is limited to 65535x65535 since it cannot signal anything larger; PNG has no signaling limits but I assume there will be some dimension limits implemented (since PNG can represent huge images in few bytes too, e.g. single-color images).

> The Main profile has two levels. Level 5 is suitable for end-user image delivery, including web browsers and mobile apps. Level 10 corresponds to a broad range of use cases such as image authoring workflows, print, scientific applications, satellite imagery, etc. > > Levels are defined in such a way that if a decoder supports level N, it also supports lower levels. > > Unless signalled otherwise, a JPEG XL codestream is assumed to be conforming to the Main profile, level 5.

Alternatively, Chrome uses `max_decoded_bytes` as a global limit for all formats (from what I can see)

Seems to have handling for high bit-depth images using half-float too <https://chromium.googlesource.com/chromium/src/+/1ade7e92edd967c0d54c64f262f9c149b48d0a96/third_party/blink/renderer/platform/image-decoders/image_decoder.cc#79>

<@179701849576833024> I see you updated your comment, not sure if you want to append it and mention `max_decoded_bytes` too, which the other formats seem to use Depends if you want to match Level 5 with `1024 * 1024 * 1024`, or match the other formats in Chrome with `max_decoded_bytes`

Eh, it's pretty close to max decoded bytes anyway

Ah, fair

Since integration in Chromium has started, I'm wondering that exotic JXL variants will appear, and it's not very clear how CMYK, CMYKA, CMYKOGV, and other exotic formats should be handled in current libjxl API. FOr CMYKA should it be num_color_channels = 5 && alpha_bits or num_color_channels = 3 &&. num_extra_channels = 2 && alpha_bits or num_color_channels == 4 && num_extra_channels ==1 && alpha_bits ?

This seems to be over generalized for the one who don't have access to spec

num_color_channels = 3 (CMY, signalled as RGB with CMYK ICC profile), one extra channel of kind Black, one extra channel of kind Alpha

So is it` num_color_channels = 3 &&. num_extra_channels = 2 && alpha_bits` ? I don't see any API allowing to distinguish types of extra channels in libjxl

I'm not familiar with libjxl API, but there should be one?

this might be more relevant for https://discord.com/channels/794206087879852103/804324493420920833

Moved to https://discord.com/channels/794206087879852103/804324493420920833/1451654298328105173 (Message link)

any guesses on whether we're going to see Chrome or Firefox integration of jxl-rs in an unstable release first?

Firefox still has a chain of around 5 blocking issues to fix first, Chrome is mostly signed off but probably next year in case of issues cropping up

also it's generally considered bad juju to submit non-trivial stuff around Christmas

absolutely

anyone who wants to become a villain should do so

no better time for overtime

After leaving some comments with advice, they got their online converter to do JPEG transcoding instead of lossless encoding https://www.reddit.com/r/jpegxl/comments/1plukes/comment/nuxptk8/

https://picperf.io/convert/jpeg-to-jpegxl

at what effort? given even e1 gives the size decrease in instant transcodes, im curious as to wether theyre trying to max the byte reductions with injustified high effort and metadata wipe

just tried a 100 and 30 megapixel jpg. fast but got a 7 kilobyte output (used firefox but fails in chrome too). 10 megapixels and ultratall 6mp jpg worked. is there a maximum resolution ?

Libraw's first official release with JXL DNG just landed https://github.com/LibRaw/LibRaw/releases/tag/0.22.0

My tree may be empty, but it looks like I'm still getting a gift this Christmas

Can't wait for v0.12 so we can have Faster Decoding DNGs

anyone got a list of devices that generate dng **1.7**? software and devices almost never specify wich dng spec version they support

Aaand they deleted it while I was asleep....

yeah getting a 404 too

probably just a minor continuity blip, refreshed 0.21 ought to be split before main as 0.22 sets its dedicated tag for lts maintainance

if you want it *right now*, here's a dl link - **libraw.org/data/LibRaw-0.22.0-Win64.zip** - **libraw.org/data/LibRaw-0.22.0-macOS.zip**

the full changelog is listed in the archive

jxl support is added through adobe's DNG converter 1.7.x - any efficiency improvements in upstream sdk probably could trickle down without a minor spec refresh but not libjxl

reddit submission deleted. was this not meant to go public yet ?

The SDK uses libjxl

Because the link was dead it got downvoted into oblivion, I'll just remake it when they re-release it

files above if you need them

Well that's nice, they used Oxide for DNG decoding https://github.com/dnglab/dnglab/pull/562

Ezgif updated their JXL support to add JPEG transcoding and client side encoding https://www.reddit.com/r/jpegxl/comments/1plukes/comment/nxm2h09/

https://ezgif.com/jpg-to-jxl-bulk-converter

jxl-rs was merged into Chromium. https://chromium-review.googlesource.com/c/chromium/src/+/7319379 Kinda crazy chrome will probably beat firefox to it

does this mean it'll be in the next release?

or will it be in canary first or something?

I'm not very familiar with Chrome's release process

doubt, it should normally go into canary first with a flag - planned built by default but enabled by default might not come this soon. origin trials can forcefully activate the flag with for specific websites to test impact

https://github.com/chromium/chromium/commit/3badff27281339878293e935a5e0fbb41da553bf

assuming its complete (builds and flags), i presume canary should be available to try tomorrow (newer than *145.0.7623.1*)

it will take a while, this is part 2/3 - the actuall wiring runs in another CL! but we are getting there!

For reference, that one is here: <https://chromium-review.googlesource.com/c/chromium/src/+/7184969/74>

yes, once that is in canary, about://flags is your friend 🥳

https://tenor.com/view/fast-cat-cat-excited-jumping-gif-5054843775616689213

I did want to ask, is the Eager progressive mode being used/tested at all? <https://github.com/libjxl/jxl-rs/blob/main/jxl/src/api/options.rs#L10> It's what allows Progressive_DC to render (I think) and there was previously a discussion around disabling the current Progressive_AC in favour of it by default Progressive AC is what gives an intermediary between 1:8 DC and full quality, Progressive DC allows any resolution up to 1:8 in powers of 2 (8x8, 16x16, 32x32, ect) Progressive lossless may also be effected, and may not work at all without Eager, but I haven't been able to test it myself. Thanks for all the hard work on Chrome!

from my understanding, it ends up in FullFrame mode so no eager. we'd need to do this in jxl-rs first i guess!

It will probably land in 146 since 145 will be cut on Monday

exciting!

<@794205442175402004> it would be cool to see more of those Cloudinary graphs covering the rollout phases of JXL in Chrone and Firefox, when that happens <:BlobYay:806132268186861619>

https://wasm-vips.kleisauke.nl/playground

I will certainly keep an eye on that!

this is what it looks like for now, basically saturation corresponding to the market share of iPhones. It's funny to see we always get spikes around holidays (thanksgiving and xmas/eoy) when people are doing more stuff on their phones and less on their desktop/laptop.

noice

can I share that graph elsewhere?

oh wow <@208917283693789185> I didn't know you were here!

really cool thing you've made

Thank you! It's one of my pet projects. 🙂

This has now been deployed. For example: https://wsrv.nl/?url=https://github.com/libjxl/conformance/raw/master/testcases/animation_icos4d/input.jxl&n=-1&output=webp However, some custom bitdepth images are currently broken due to the issue described in PR <https://github.com/libvips/libvips/pull/4830> (e.g. <https://wsrv.nl/?url=https://github.com/libjxl/conformance/raw/master/testcases/sunset_logo/input.jxl&output=png>).

you made wsrv too??

I was actually looking at that

Yes, one of my other pet projects.

I like your pet projects

good glitchart in the PR

whats new for android?

Why do you ask? Was there anything announced?

no, i just search a android gallery app with zooming for jpegxl

we have some in <#822120855449894942>

I don't think Fossify Gallery is what he's looking for though https://github.com/FossifyOrg/Gallery/issues/252

i think that was fixed at some point but its still an issue with avif

https://github.com/FossifyOrg/Gallery/issues/318

I misread that the first few times, didn't realise we hit 1B/d

https://reshade.me/releases/10207-6-7 JXL screenshot feature in official reshade build now

Thanks <@274048677851430913>

it feels like things are moving so quickly now :D

love to see it

Inteeeresting... They removed it from the blog and redirected the URL https://aboutsignal.com/news/signal-ios-update-bug-fixes-jpeg-xl-and-pinned-messages-are-getting-closer/

Part 3/3 if I'm not mistaken https://github.com/chromium/chromium/commit/8215ebd5eb9d45b42bbc68e1ceff039a319b35d6

correct

if so, i presume itll be in upcoming canary build *after 145.0.7631.2*

this is oddly satisfying

I believe it should be in 146.x

(branch cut for 145 was today)

You can check https://chromiumdash.appspot.com/commit/8215ebd5eb9d45b42bbc68e1ceff039a319b35d6 for which build it's shipped with

It says `Landed 145.0.7632.0`, so I think it might've slipped in

https://chromium.googlesource.com/chromium/src/+log/refs/tags/145.0.7632.0 It's so close, 80 minutes before the last commit

maybe I'm going to install chromium canary build

canary is released you'd need to opt in via chrome://flags/ (search jxl) - and make sure to restart canar atleast once!

also think it might slipt in 🙂 but we will see, the label/tag on chromiumdash does give me hope

I just tested https://random-stuff.jakearchibald.com/apps/img-decode-bench/ and JXL is 20x slower than AVIF I wonder if the SIMD feature is not enabled

it should, no matter what build flavor, jxl-rs always uses release/optimized flags

but perfromance is still a thing, getting it in was prio.

it's happening it's happening

Is JXL really functional on Chrome Canary now?

It's a default feature of jxl_cli but I didn't see where it gets enabled in Chromium

if you enable it with chrome://flags (and restart once) yes

Great so it's not a placeholder flag there

time to compress the web

jxl-rs has SIMD but it's still singlethreaded now

and it doesn't match the performance of singlethreaded libjxl yet

yep that's definitely working, including hdr, awesome no idea if this is even supposed to be a supported use case for jxl in "normal" viewers, but i noticed that a jxl converted 1:1 from jxr (hdr using linear half float srgb, with (1,1,1) = 80 nits white) is not displayed as hdr in chrome. it does work when importing into krita though jxlinfo for reference: ``` JPEG XL file format container (ISO/IEC 18181-2) JPEG XL image, 3840x2160, (possibly) lossless, 16-bit float (5 exponent bits) RGB+Alpha intensity_target: 80.000000 nits min_nits: 0.000000 relative_to_max_display: 0 linear_below: 0.000000 Color space: RGB, D65, sRGB primaries, Linear transfer function, rendering intent: Relative ``` i assume the issue there is that there's no indication for the maximum luminance in the image, so it's hard to tell if it's even supposed to be hdr or not.

I specifically left a comment warning about comparing to other formats https://issues.chromium.org/issues/462919304#comment22

Can you check if `features = ["all-simd"]` should be added here: https://source.chromium.org/chromium/chromium/src/+/main:third_party/rust/chromium_crates_io/Cargo.toml;l=30